From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25490 invoked by alias); 11 Nov 2007 06:46:58 -0000 Received: (qmail 25474 invoked by uid 22791); 11 Nov 2007 06:46:57 -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; Sun, 11 Nov 2007 06:46:54 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id DC33C3BFC5; Sat, 10 Nov 2007 22:28:53 -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: <87hcjtllau.fsf@escher.local.home> References: <87r6j6rvn3.fsf@escher.local.home> <87hcjtllau.fsf@escher.local.home> Content-Type: text/plain Date: Sun, 11 Nov 2007 06:46:00 -0000 Message-Id: <1194763094.16917.278.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/msg00083.txt.bz2 Hi Stephen, See questions inline: On Sun, 2007-11-11 at 00:42 +0100, Stephen Berman wrote: > I recently experienced an abort in CVS Emacs and was unable to get a > backtrace from GDB. The Emacs bug causing the abort was fixed, but > Richard Stallman responded to the lack of a backtrace with this comment: > > > That could be a serious problem in GDB. It would be good to talk > > with GDB developers about how to investigate it. Since the bug's > > cause is known, they could focus on figuring out why GDB fails > > to give a backtrace. Out of curiosity, and because RMS seems to think it's relevant -- what is the bug's cause? > Here is the GDB-relevant part of my bug report about the abort (Emacs > was built using the GTK+ toolkit): What's your host architecture? OS? How is gdb configured (host-target tuple)? > > I attempted to debug in gdb; here's the output when the abort occurs: > > > > (emacs:19177): Gtk-WARNING **: Can't set a parent on widget which has a parent > > > > > > Gtk-ERROR **: file gtkcontainer.c: line 2641 (gtk_container_propagate_expose): assertion failed: (child->parent == GTK_WIDGET (container)) > > aborting... > > [Switching to Thread 0xb6ec66c0 (LWP 19177)] > > > > Breakpoint 1, abort () at emacs.c:431 > > 431 kill (getpid (), SIGABRT); > > > > At this point my desktop (I tried in KDE, GNOME and twm, same behavior > > in all) is totally locked up, but I can switch to a virtual tty and > > there kill emacs with SIGKILL (kill -9); SIGTERM (kill -15) does not do > > the job. Making sure that I understand -- you ran emacs under gdb, you set a breakpoint at abort, you hit the breakpoint -- and your desktop is locked up? That seems unusual -- do you have any idea of the cause? Is it possible that emacs is in an infinite recursion and has consumed all of virtual memory, or something of the sort? > This releases the desktop, but gdb delivers no further > > feedback: > > > > (gdb) xbacktrace OK, I'm not familiar with that command. "xbacktrace"? Grepping my gdb source tree for "xbacktrace" produces no results. > > Cannot access memory at address 0x8321b6c Is that a valid address for your architecture? > > (gdb) bt > > #0 abort () at emacs.c:431 > > Cannot access memory at address 0xbfd6836c > > Cannot access memory at address 0x8321b6c > > > > Setting a break point at abort() in emacs.c makes no difference. I > > don't have the GTK+ source code so I cannot debug it there. > > Does anyone have an idea why there was no backtrace? > > Steve Berman >