Re: GDB cannot access memory after Emacs abort

On Sun, 11 Nov 2007 09:44:23 +0200 Eli Zaretskii
<elizgnu.org> wrote:

>                         the upshot of all this is that
`bt' doesn't
> work, as shown below:
>
>> > >   (gdb) bt
>> > >   #0  abort () at emacs.c:431
>> > >   Cannot access memory at address
0xbfd6836c
>> > >   Cannot access memory at address
0x8321b6c
>
> Stack overflow, maybe?

Due to an infinite loop in Emacs?  (I don't know if the bug
I reported
caused this, maybe Jan D. can answer that.)  But as I
mentioned in my
other followup, I've never experienced an infinite loop in
Emacs that
locked up X.  If it was due to a stack overflow, does that
mean GDB is
above suspicion in this case?

Steve Berman

On Mon, 2007-11-12 at 00:01 +0100, Stephen Berman wrote:
> On Sun, 11 Nov 2007 09:44:23 +0200 Eli Zaretskii
<elizgnu.org> wrote:
> 
> >                         the upshot of all this is
that `bt' doesn't
> > work, as shown below:
> >
> >> > >   (gdb) bt
> >> > >   #0  abort () at emacs.c:431
> >> > >   Cannot access memory at address
0xbfd6836c
> >> > >   Cannot access memory at address
0x8321b6c
> >
> > Stack overflow, maybe?
> 
> Due to an infinite loop in Emacs?  (I don't know if the
bug I reported
> caused this, maybe Jan D. can answer that.)  But as I
mentioned in my
> other followup, I've never experienced an infinite loop
in Emacs that
> locked up X.  If it was due to a stack overflow, does
that mean GDB is
> above suspicion in this case?

No, it just means we don't yet have enough information to
diagnose it.
Stack overflow could potentially produce a state that was
too corrupt
for gdb to decypher, but we don't know yet if that's the
case.

Now that I know that the target is x86-linux, I can
reasonably 
speculate that 0xbfd6836c looks like a stack address, and 
0x8321b6c looks like a code or data address.  But so far
those
are only guesses, and it isn't yet clear why gdb would be
unable
to access memory at those addresses.

I wonder -- after the above happens, what do you get if you

type the following at the (gdb) prompt:

  x /i $eip

If you get the same error (Cannot access memory at ...), 
then perhaps gdb has lost contact with the child process
entirely, and cannot access *any* memory.

If not, then some child memory is accessable and some is
not
(which is not entirely surprising) -- and the question
becomes,
why is gdb trying to read from memory that is not
accessable?