public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Michael Snyder <msnyder@specifix.com>
To: Stephen Berman <Stephen.Berman@gmx.net>
Cc: gdb@sources.redhat.com
Subject: Re: GDB cannot access memory after Emacs abort
Date: Thu, 15 Nov 2007 01:00:00 -0000	[thread overview]
Message-ID: <1195087856.12695.90.camel@localhost.localdomain> (raw)
In-Reply-To: <87r6ishbsd.fsf@escher.local.home>

On Wed, 2007-11-14 at 20:22 +0100, Stephen Berman wrote:
> On Wed, 14 Nov 2007 03:50:53 -0800 Michael Snyder <msnyder@specifix.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".


  reply	other threads:[~2007-11-15  1:00 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87r6j6rvn3.fsf@escher.local.home>
2007-11-10 23:50 ` Stephen Berman
2007-11-11  6:46   ` Michael Snyder
2007-11-11  7:44     ` Eli Zaretskii
2007-11-11 23:05       ` Stephen Berman
2007-11-12  4:18         ` Eli Zaretskii
2007-11-12  5:24         ` Michael Snyder
2007-11-13 22:40           ` Stephen Berman
2007-11-13 23:20             ` Michael Snyder
2007-11-13 23:28               ` Dan Nicolaescu
2007-11-14 10:00                 ` Stephen Berman
2007-11-13 23:57             ` Andreas Schwab
2007-11-11 19:22     ` Daniel Jacobowitz
2007-11-11 23:10       ` Stephen Berman
2007-11-12  0:39         ` Daniel Jacobowitz
2007-11-12 17:47         ` Jim Blandy
2007-11-12 19:44           ` Andreas Schwab
2007-11-13 22:36             ` Stephen Berman
2007-11-13 22:34           ` Stephen Berman
2007-11-13 23:14             ` Michael Snyder
2007-11-14  9:48               ` Stephen Berman
2007-11-13 23:51             ` Andreas Schwab
2007-11-12  7:39       ` Vladimir Prus
2007-11-13 22:36         ` Stephen Berman
2007-11-13 23:24           ` Michael Snyder
2007-11-14  9:50             ` Stephen Berman
2007-11-14 12:00               ` Michael Snyder
2007-11-14 19:24                 ` Stephen Berman
2007-11-15  1:00                   ` Michael Snyder [this message]
2007-11-11 23:01     ` Stephen Berman
2007-11-12  5:15       ` Michael Snyder
2007-11-14  9:55         ` Stephen Berman
2007-11-14 12:00           ` Michael Snyder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1195087856.12695.90.camel@localhost.localdomain \
    --to=msnyder@specifix.com \
    --cc=Stephen.Berman@gmx.net \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).