Re: GDB cannot access memory after Emacs abort

[Michael Snyder <msnyder at specifix dot com>]

On Mon, 2007-11-12 at 00:01 +0100, Stephen Berman wrote:
> On Sun, 11 Nov 2007 09:44:23 +0200 Eli Zaretskii <eliz@gnu.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?