From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17326 invoked by alias); 15 Nov 2007 01:00:34 -0000 Received: (qmail 17312 invoked by uid 22791); 15 Nov 2007 01:00:33 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 15 Nov 2007 01:00:29 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id DDF893BD5A; Wed, 14 Nov 2007 16:41:35 -0800 (PST) Subject: Re: GDB cannot access memory after Emacs abort From: Michael Snyder To: Stephen Berman Cc: gdb@sources.redhat.com In-Reply-To: <87r6ishbsd.fsf@escher.local.home> References: <87r6j6rvn3.fsf@escher.local.home> <87hcjtllau.fsf@escher.local.home> <1194763094.16917.278.camel@localhost.localdomain> <20071111192237.GA11728@caradoc.them.org> <87d4uddbjw.fsf@escher.local.home> <1194995698.12695.42.camel@localhost.localdomain> <876405i2e3.fsf@escher.local.home> <1195041053.12695.55.camel@localhost.localdomain> <87r6ishbsd.fsf@escher.local.home> Content-Type: text/plain Date: Thu, 15 Nov 2007 01:00:00 -0000 Message-Id: <1195087856.12695.90.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-4.fc7) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-11/txt/msg00153.txt.bz2 On Wed, 2007-11-14 at 20:22 +0100, Stephen Berman wrote: > On Wed, 14 Nov 2007 03:50:53 -0800 Michael Snyder 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".