Re: GDB cannot access memory after Emacs abort

On Wed, 14 Nov 2007 03:50:53 -0800 Michael Snyder
<msnyderspecifix.com> wrote:

> 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.

What does it mean that in frame #4 of the backtrace the
symbol
gtk_container_propagate_expose from
/usr/lib/libgtk-x11-2.0.so.0 is
referenced but starting in the next stack frame there is
only ?? with
reference to the same library?  That gdb is finding some but
not all
symbols?  Note that when I attached the emacs process to
gdb, it
returned a slew of message like this:

Reading symbols from /usr/lib/libgtk-x11-2.0.so.0...done.
Loaded symbols for /usr/lib/libgtk-x11-2.0.so.0
Reading symbols from /usr/lib/libgdk-x11-2.0.so.0...done.
Loaded symbols for /usr/lib/libgdk-x11-2.0.so.0
Reading symbols from /usr/lib/libatk-1.0.so.0...done.
Loaded symbols for /usr/lib/libatk-1.0.so.0
Reading symbols from
/usr/lib/libgdk_pixbuf-2.0.so.0...done.
...

> Are these libraries installed in an unusual location?

They are all in /usr/lib AFAICT; I didn't install them
myself, that's
where the distro I use (openSUSE) put them.

> Is LD_LIBRARY_PATH set correctly (in the gdb shell)?

How do I determine this (show env does not list
LD_LIBRARY_PATH)?

> Is there a location (other than /lib, /usr/lib etc)
> where you could tell gdb to find the libraries?

Not that I know of.

Here's an additional datapoint, FWIW: I induced the abort
again, and
this time the backtrace was slightly different from the one
I posted
before:

#0  abort () at emacs.c:431
#1  0xb790f26a in g_logv () from /usr/lib/libglib-2.0.so.0
#2  0xb790f2a9 in g_log () from /usr/lib/libglib-2.0.so.0
#3  0xb790f320 in g_assert_warning () from
/usr/lib/libglib-2.0.so.0
#4  0xb7c05195 in gtk_container_propagate_expose () from
/usr/lib/libgtk-x11-2.0.so.0
#5  0xb7c051c1 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#6  0x0833e1b0 in ceil ()
#7  0x086c35c0 in ?? ()
#8  0x087c59f8 in ?? ()
#9  0xb7cadb6a in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#10 0xb7ec4ff4 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#11 0x0833e1b0 in ceil ()
#12 0xbfea1228 in ?? ()
#13 0xb7c7eb42 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#14 0x086c35c0 in ?? ()
#15 0xbfea1268 in ?? ()
#16 0xb7c051a0 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#17 0xbfea1268 in ?? ()
#18 0x0000001e in ?? ()
#19 0x40000036 in ?? ()
#20 0xbfea1238 in ?? ()
#21 0xb7ec4ff4 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#22 0x0833e1b0 in ceil ()
#23 0x0833e1b0 in ceil ()
#24 0xbfea1248 in ?? ()
#25 0xb7c05be7 in gtk_container_forall () from
/usr/lib/libgtk-x11-2.0.so.0
Backtrace stopped: previous frame inner to this frame
(corrupt stack?)

What is the significance of the stack frames
#6  0x0833e1b0 in ceil ()
and so on (note it's always the same address)?

Thanks again for your helpful comments.

Steve Berman

On Wed, 2007-11-14 at 20:22 +0100, Stephen Berman wrote:
> On Wed, 14 Nov 2007 03:50:53 -0800 Michael Snyder
<msnyderspecifix.com> wrote:
> 
> > 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.
> 
> What does it mean that in frame #4 of the backtrace the
symbol
> gtk_container_propagate_expose from
/usr/lib/libgtk-x11-2.0.so.0 is
> referenced but starting in the next stack frame there
is only ?? with
> reference to the same library?  

It means that:
For frame #4, gdb found a PC address that fit inside the
bounds
of the text section of libgtk-x1-2.0.so, and corresponded
with 
the function "gtk_container_propagate_expose" from
that library.

For frame #5, gdb found a PC address that also fit the
address
range of that library, but did not correspond with any
function
symbol.

For frame #6, gdb found a PC address that did not match
with
any known section of an object file (eg. shared library),
and
could not be matched against any known function symbol.


> That gdb is finding some but not all
> symbols?  Note that when I attached the emacs process
to gdb, it
> returned a slew of message like this:
> 
> Reading symbols from
/usr/lib/libgtk-x11-2.0.so.0...done.
> Loaded symbols for /usr/lib/libgtk-x11-2.0.so.0
> Reading symbols from
/usr/lib/libgdk-x11-2.0.so.0...done.
> Loaded symbols for /usr/lib/libgdk-x11-2.0.so.0
> Reading symbols from /usr/lib/libatk-1.0.so.0...done.
> Loaded symbols for /usr/lib/libatk-1.0.so.0
> Reading symbols from
/usr/lib/libgdk_pixbuf-2.0.so.0...done.

OK -- do you know whether these messages accounted for all 
known libraries used by emacs?  Could there be some
libraries
that are missing (therefore gdb does not have symbols for)?

...

> What is the significance of the stack frames
> #6  0x0833e1b0 in ceil ()
> and so on (note it's always the same address)?

It may be garbage.  The stack unwind may have become
corrupt
by that point (I can't tell).  If we assume it is
meaningful, 
it means that gdb found a PC for the stack frame for which
the nearest corresponding function symbol is
"ceil".