From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17045 invoked by alias); 14 Nov 2007 09:48:19 -0000 Received: (qmail 17037 invoked by uid 22791); 14 Nov 2007 09:48:18 -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:48:15 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IsEqq-0003Jb-2u for gdb@sources.redhat.com; Wed, 14 Nov 2007 09:48:04 +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:48:04 +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:48:04 +0000 To: gdb@sources.redhat.com From: Stephen Berman Subject: Re: GDB cannot access memory after Emacs abort Date: Wed, 14 Nov 2007 09:48:00 -0000 Message-ID: <877ikli2ev.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> <87hcjsgzea.fsf@escher.local.home> <87hcjpdble.fsf@escher.local.home> <1194995136.12695.31.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/msg00127.txt.bz2 On Tue, 13 Nov 2007 15:05:36 -0800 Michael Snyder wrote: > On Tue, 2007-11-13 at 23:28 +0100, Stephen Berman wrote: [...] >> Note, however, that this only happens when running emacs under gdb; if I >> start emacs directly from the shell, induce the abort, then the Emacs >> window vanishes, but the desktop remains responsive and no other >> problems are apparent. > > Well that's understandable. emacs has grabbed the focus, presumably > something you are only supposed to do for a brief interval. If emacs > aborts, it will let go of the focus when it dies, but if gdb stops it > from dying, it can't let go of the focus. > > This would happen with any resource that a debugged program > had a lock on. You can create deadlocks when you debug things > that have locks on resources. > > That's a fact of life. Ok, I understand this now. >> > Am I correct in understanding that: >> > - your X session locks up, and all your windows are unresponsive, not >> > just GDB's and Emacs >> >> Yes, all open X apps are unresponsive to keyboard or mouse input, but >> the apps continue to operate normally, e.g., the newsticker scrolls, the >> displays in gkrellm (time, CPU activity, free memory, etc.) continue to >> be updated. > > I would prefer if we could set this issue aside. > I don't believe it is a gdb issue. The backtrace > issue is what we should discuss. See my followup to your suggestion to attach the emacs process to gdb. Steve Berman