Re: GDB cannot access memory after Emacs abort

[Michael Snyder <msnyder@specifix.com>]

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