From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18426 invoked by alias); 14 Nov 2007 09:50:18 -0000 Received: (qmail 18416 invoked by uid 22791); 14 Nov 2007 09:50:17 -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; Wed, 14 Nov 2007 09:50:14 +0000 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1IsEsk-0003cF-Vp for gdb@sources.redhat.com; Wed, 14 Nov 2007 09:50:03 +0000 Received: from i577bc647.versanet.de ([87.123.198.71]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Nov 2007 09:50:02 +0000 Received: from Stephen.Berman by i577bc647.versanet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Nov 2007 09:50:02 +0000 To: gdb@sources.redhat.com From: Stephen Berman Subject: Re: GDB cannot access memory after Emacs abort Date: Wed, 14 Nov 2007 09:50:00 -0000 Message-ID: <876405i2e3.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> 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/msg00128.txt.bz2 On Tue, 13 Nov 2007 15:14:58 -0800 Michael Snyder wrote: > On Tue, 2007-11-13 at 23:29 +0100, Stephen Berman wrote: [...] >> But as I pointed out in my followup to Jim Blandy, the lockup only >> happens when emacs aborts while running under gdb; starting emacs >> directly from the shell and inducing the abort does not lock up the >> desktop. > > Hoping you have seen my other replies, I believe we understand > why this happens. > > I do have a suggestion. > > Run gdb from a non-GUI terminal, eg. a virtual console. > > For example, launch emacs normally, WITHOUT gdb, from gnome/kde/gtk/X. > Then go to a virtual console, use 'ps' to determine the process id of > emacs, then start gdb and use the "attach" command to get control of > emacs from gdb. > > Now return to the GUI console, and make emacs crash. > > When you return to the virtual console, you should be able to debug. Thanks for this suggestion, it worked. Here's the backtrace: #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 ?? () #9 0xb7d23b6a in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #10 0xb7f3aff4 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #11 0x085c2d00 in ?? () #12 0xbfef82a8 in ?? () #13 0xb7cf4b42 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #14 0x086c0a08 in ?? () #15 0xbfef82e8 in ?? () #16 0xb7c7b1a0 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #17 0xbfef82e8 in ?? () #18 0x0000001e in ?? () #19 0x40000036 in ?? () #20 0xbfef82b8 in ?? () #21 0xb7f3aff4 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #22 0x085c2d00 in ?? () #23 0x085c2d00 in ?? () #24 0xbfef82c8 in ?? () #25 0xb7c7bbe7 in gtk_container_forall () from /usr/lib/libgtk-x11-2.0.so.0 Backtrace stopped: previous frame inner to this frame (corrupt stack?) 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. In any case, the fact that I have gotten a backtrace now evidently absolves GDB of the suspicion that it had a bug preventing a backtrace :-). And since the Emacs bug causing the abort was already fixed, and the issue of the desktop lockup has been explained, I guess we can declare this issue closed, unless someone thinks the above backtrace is still reason for concern. Steve Berman