Re: GDB cannot access memory after Emacs abort

[Michael Snyder <msnyder@specifix.com>]

On Tue, 2007-11-13 at 23:28 +0100, Stephen Berman wrote:
> On Sun, 11 Nov 2007 21:15:55 -0800 Michael Snyder <msnyder@specifix.com> wrote:
> 
> > 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
> >> >
> [...]
> > I wonder -- after the above happens, what do you get if you 
> > type the following at the (gdb) prompt:
> >
> >   x /i $eip
> 
> After the abort occurs, the desktop locks up, I switch to a virtual tty
> and kill -9 the emacs process, releasing the desktop, then type what you
> said at the gdb prompt and get this:
> 
> 0x80f9e56 <abort+6>:    Cannot access memory at address 0x80f9e56

Oh yes.  I understand that now, thanks.

What we need, I guess, is to get back into control of 
the gdb without killing the emacs.  Otherwise it is
kind of hard to debug this gdb problem further.


> > 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.
> 
> Yes, this is also what Jim Blandy surmised. 

Well, as I now understand, that's because you killed the emacs.


> But, as I ask in my
> response to Blandy, why does the desktop lock up only happen when the
> emacs abort is induced while running under gdb?

I believe this is now well understood, and not a gdb problem.
In a nutshell, your emacs process has a lock on a shared 
resource (the X keyboard-and-mouse "focus").  It is intended
to keep that lock only briefly, but while in posession of the
lock, it aborts.

Normally an abort would result in the freeing of the lock, 
but since gdb stops the emacs process from exiting, the lock
is not freed, resulting in a deadlock when some other process
(eg. xterm) needs the lock.

This is a problem, but a normal and predictable one.
GDB cannot tell when a debugged process is in posession 
of a lock that will cause other processes to deadlock, 
and it has no way of freeing such locks.

This could happen with any shared, lockable resource.