Re: GDB cannot access memory after Emacs abort

On Sun, 11 Nov 2007 14:22:37 -0500 Daniel Jacobowitz
<drowfalse.org> wrote:

> On Sat, Nov 10, 2007 at 10:38:14PM -0800, Michael
Snyder wrote:
>> > > At this point my desktop (I tried in KDE,
GNOME and twm, same behavior
>> > > in all) is totally locked up, but I can
switch to a virtual tty and
>> > > there kill emacs with SIGKILL (kill -9);
SIGTERM (kill -15) does not do
>> > > the job. 
>> 
>> 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.

That's interesting; do you have any pointers to further
information
about this?  Yet, as I mentioned in my other followups, this
has never
happened to me before when running Emacs under gdb, even
when it's in an
infinite loop.  It sounds like you, too, don't suspect a bug
in GDB that
prevented getting a backtrace.

Steve Berman

On Mon, Nov 12, 2007 at 12:01:33AM +0100, Stephen Berman
wrote:
> That's interesting; do you have any pointers to further
information
> about this?

Nope, sorry.

-- 
Daniel Jacobowitz
CodeSourcery

Stephen Berman <Stephen.Berman at gmx.net> writes:
> On Sun, 11 Nov 2007 14:22:37 -0500 Daniel Jacobowitz
<drowfalse.org> wrote:
>
>> On Sat, Nov 10, 2007 at 10:38:14PM -0800, Michael
Snyder wrote:
>>> > > At this point my desktop (I tried in
KDE, GNOME and twm, same behavior
>>> > > in all) is totally locked up, but I
can switch to a virtual tty and
>>> > > there kill emacs with SIGKILL (kill
-9); SIGTERM (kill -15) does not do
>>> > > the job. 
>>> 
>>> 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.
>
> That's interesting; do you have any pointers to further
information
> about this?  Yet, as I mentioned in my other followups,
this has never
> happened to me before when running Emacs under gdb,
even when it's in an
> infinite loop.  It sounds like you, too, don't suspect
a bug in GDB that
> prevented getting a backtrace.

Actually, these are legit X Windows behavior; they're called
'server
grabs'.  They're supposed to be rare (for obvious reasons),
but if
Emacs died while it had the server grabbed, you'd certainly
not be
able to interact with the debugger in another window.

Am I correct in understanding that:
- your X session locks up, and all your windows are
unresponsive, not
  just GDB's and Emacs
- you kill Emacs via some other means, which unfreezes your
X session
- now you can interact with GDB again, but GDB can't get the
backtrace.

GDB produces backtraces by reading memory from the process. 
So if my
sequence above is correct, once you have killed the Emacs
process in
another window, then it's expected that GDB won't be able to
get its
backtrace.