This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GDB cannot access memory after Emacs abort
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?