Re: GDB cannot access memory after Emacs abort

[Michael Snyder <msnyder@specifix.com>]

On Tue, 2007-11-13 at 23:29 +0100, Stephen Berman wrote:
> On Mon, 12 Nov 2007 10:38:36 +0300 Vladimir Prus <ghost@cs.msu.su> wrote:
> 
> > Daniel Jacobowitz wrote:
> >
> >> On Sat, Nov 10, 2007 at 10:38:14PM -0800, Michael Snyder wrote:
> >>> 
> >>> Making sure that I understand -- you ran emacs under gdb,
> >>> you set a breakpoint at abort, you hit the breakpoint --
> >>> and your desktop is locked up?
> >>> 
> >>> That seems unusual -- do you have any idea of the cause?
> >> 
> >> This is pretty common when debugging X programs, IIRC.  I believe
> >> there's some ways in which an application can "own" a display while
> >> something is in progress.
> >
> > I believe it's XGrabPointer, which causes all mouse and/or keyboard
> > event to be delivered to specific application. If that application is
> > stopped by gdb, it means, in effect, that events are not processed at all.
> >
> > I have no idea if that's the cause, since the emacs diff posted in another
> > email does not have any apparent locking thing, but it very likely.
> 
> But as I pointed out in my followup to Jim Blandy, the lockup only
> happens when emacs aborts while running under gdb; starting emacs
> directly from the shell and inducing the abort does not lock up the
> desktop.

Hoping you have seen my other replies, I believe we understand
why this happens.

I do have a suggestion.

Run gdb from a non-GUI terminal, eg. a virtual console.

For example, launch emacs normally, WITHOUT gdb, from gnome/kde/gtk/X.
Then go to a virtual console, use 'ps' to determine the process id of
emacs, then start gdb and use the "attach" command to get control of
emacs from gdb.

Now return to the GUI console, and make emacs crash.

When you return to the virtual console, you should be able to debug.