From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24141 invoked by alias); 11 Nov 2007 23:01:21 -0000 Received: (qmail 24129 invoked by uid 22791); 11 Nov 2007 23:01:20 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 11 Nov 2007 23:01:16 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IrLni-0006xg-Ob for gdb@sources.redhat.com; Sun, 11 Nov 2007 23:01:10 +0000 Received: from i577bf47d.versanet.de ([87.123.244.125]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Nov 2007 23:01:10 +0000 Received: from Stephen.Berman by i577bf47d.versanet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 11 Nov 2007 23:01:10 +0000 To: gdb@sources.redhat.com From: Stephen Berman Subject: Re: GDB cannot access memory after Emacs abort Date: Sun, 11 Nov 2007 23:01:00 -0000 Message-ID: <87k5oogzf3.fsf@escher.local.home> References: <87r6j6rvn3.fsf@escher.local.home> <87hcjtllau.fsf@escher.local.home> <1194763094.16917.278.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux) 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/msg00086.txt.bz2 On Sat, 10 Nov 2007 22:38:14 -0800 Michael Snyder wrote: > 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? It had to do with the handling of named icons in GTK+ tool bars. I don't know the code well enough to say more, but the diff is here: http://cvs.savannah.gnu.org/viewvc/emacs/emacs/src/gtkutil.c?r1=1.120&r2=1.121&pathrev=MAIN >> 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)? Linux escher 2.6.22.12-0.1-default i686 athlon i386 GNU/Linux (openSUSE 10.3) GNU gdb 6.6.50.20070726-cvs This GDB was configured as "i586-suse-linux". > 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? Yes (as Eli Zaretskii pointed out, Emacs set a breakpoint at abort). > That seems unusual -- do you have any idea of the cause? No! I'm hoping someone here might have some insight. > Is it possible that emacs is in an infinite recursion > and has consumed all of virtual memory, or something > of the sort? This has happened on (rare) occasion, but it never locked up the desktop, I could always at least kill -9 the emacs process from within the X window system (in the case under discussion, I was able to switch to a virtual tty and kill -9 the emacs process from there, but X was locked up solid). >> > Cannot access memory at address 0x8321b6c > > Is that a valid address for your architecture? How can I determine that? Anyway, it sound like you don't suspect a bug in GDB that prevented getting a backtrace, or is that still a possibility? Steve Berman