Re: GDB cannot access memory after Emacs abort

On Mon, 12 Nov 2007 10:38:36 +0300 Vladimir Prus
<ghostcs.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.

Steve Berman

On Tue, 2007-11-13 at 23:29 +0100, Stephen Berman wrote:
> On Mon, 12 Nov 2007 10:38:36 +0300 Vladimir Prus
<ghostcs.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.