Re: GDB cannot access memory after Emacs abort

On Tue, 13 Nov 2007 15:14:58 -0800 Michael Snyder
<msnyderspecifix.com> wrote:

> On Tue, 2007-11-13 at 23:29 +0100, Stephen Berman
wrote:
[...]
>> 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.

Thanks for this suggestion, it worked.  Here's the
backtrace:

#0  abort () at emacs.c:431
#1  0xb798526a in g_logv () from /usr/lib/libglib-2.0.so.0
#2  0xb79852a9 in g_log () from /usr/lib/libglib-2.0.so.0
#3  0xb7985320 in g_assert_warning () from
/usr/lib/libglib-2.0.so.0
#4  0xb7c7b195 in gtk_container_propagate_expose () from
/usr/lib/libgtk-x11-2.0.so.0
#5  0xb7c7b1c1 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#6  0x085c2d00 in ?? ()
#7  0x086c0a08 in ?? ()
#8  0x087c31f0 in ?? ()
#9  0xb7d23b6a in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#10 0xb7f3aff4 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#11 0x085c2d00 in ?? ()
#12 0xbfef82a8 in ?? ()
#13 0xb7cf4b42 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#14 0x086c0a08 in ?? ()
#15 0xbfef82e8 in ?? ()
#16 0xb7c7b1a0 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#17 0xbfef82e8 in ?? ()
#18 0x0000001e in ?? ()
#19 0x40000036 in ?? ()
#20 0xbfef82b8 in ?? ()
#21 0xb7f3aff4 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#22 0x085c2d00 in ?? ()
#23 0x085c2d00 in ?? ()
#24 0xbfef82c8 in ?? ()
#25 0xb7c7bbe7 in gtk_container_forall () from
/usr/lib/libgtk-x11-2.0.so.0
Backtrace stopped: previous frame inner to this frame
(corrupt stack?)

I don't know if this is useful to you or any other gdb
hacker.  I don't
have the GTK+ sources installed.  Maybe someone who does can
reproduce
the abort and get a more informative backtrace.  In any
case, the fact
that I have gotten a backtrace now evidently absolves GDB of
the
suspicion that it had a bug preventing a backtrace .  And
since the
Emacs bug causing the abort was already fixed, and the issue
of the
desktop lockup has been explained, I guess we can declare
this issue
closed, unless someone thinks the above backtrace is still
reason for
concern.

Steve Berman

On Wed, 2007-11-14 at 10:48 +0100, Stephen Berman wrote:

> Thanks for this suggestion, it worked.  Here's the
backtrace:

OK, this is great!  See below.

> #0  abort () at emacs.c:431
> #1  0xb798526a in g_logv () from
/usr/lib/libglib-2.0.so.0
> #2  0xb79852a9 in g_log () from
/usr/lib/libglib-2.0.so.0
> #3  0xb7985320 in g_assert_warning () from
/usr/lib/libglib-2.0.so.0
> #4  0xb7c7b195 in gtk_container_propagate_expose ()
from /usr/lib/libgtk-x11-2.0.so.0
> #5  0xb7c7b1c1 in ?? () from
/usr/lib/libgtk-x11-2.0.so.0
> #6  0x085c2d00 in ?? ()
> #7  0x086c0a08 in ?? ()
> #8  0x087c31f0 in ?? ()
[...]

> I don't know if this is useful to you or any other gdb
hacker.  I don't
> have the GTK+ sources installed.  Maybe someone who
does can reproduce
> the abort and get a more informative backtrace. 

You don't need to have the sources installed, but 
it appears as if GDB can't find symbols for the shared
libraries.

Are these libraries installed in an unusual location?
Is LD_LIBRARY_PATH set correctly (in the gdb shell)?
Is there a location (other than /lib, /usr/lib etc)
where you could tell gdb to find the libraries?

See the built in help for "set solib-search-path"

and "set solib-absolute-prefix".

One more thing that might help is if you can install
the debuggable versions of these libraries (the ones
compiled with -g for debug symbols, and/or the ones
that have not been stripped).


>  In any case, the fact
> that I have gotten a backtrace now evidently absolves
GDB of the
> suspicion that it had a bug preventing a backtrace .  And
since the
> Emacs bug causing the abort was already fixed, and the
issue of the
> desktop lockup has been explained, I guess we can
declare this issue
> closed, unless someone thinks the above backtrace is
still reason for
> concern.

I think we're in accord -- my suggestions were just to
help you if you need to debug further (now or in future).

Michael