From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2360 invoked by alias); 13 Nov 2007 23:14:58 -0000 Received: (qmail 2351 invoked by uid 22791); 13 Nov 2007 23:14: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; Tue, 13 Nov 2007 23:14:54 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 693683C46D; Tue, 13 Nov 2007 14:56:16 -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: <87hcjpdble.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> Content-Type: text/plain Date: Tue, 13 Nov 2007 23:14:00 -0000 Message-Id: <1194995136.12695.31.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/msg00113.txt.bz2 On Tue, 2007-11-13 at 23:28 +0100, Stephen Berman wrote: > On Mon, 12 Nov 2007 09:46:43 -0800 Jim Blandy wrote: > > > Stephen Berman writes: > >> On Sun, 11 Nov 2007 14:22:37 -0500 Daniel Jacobowitz wrote: > >> > >>> On Sat, Nov 10, 2007 at 10:38:14PM -0800, Michael Snyder wrote: > >>>> > > 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? > >>> > >>> This is pretty common when debugging X programs, IIRC. I believe > >>> there's some ways in which an application can "own" a display while > >>> something is in progress. > >> > >> That's interesting; do you have any pointers to further information > >> about this? Yet, as I mentioned in my other followups, this has never > >> happened to me before when running Emacs under gdb, even when it's in an > >> infinite loop. It sounds like you, too, don't suspect a bug in GDB that > >> prevented getting a backtrace. > > > > Actually, these are legit X Windows behavior; they're called 'server > > grabs'. They're supposed to be rare (for obvious reasons), but if > > Emacs died while it had the server grabbed, you'd certainly not be > > able to interact with the debugger in another window. > > 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. > > 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. > > > - you kill Emacs via some other means, which unfreezes your X session > > Yes, by switching to a virtual tty. > > > - now you can interact with GDB again, but GDB can't get the backtrace. > > Yes. > > > GDB produces backtraces by reading memory from the process. So if my > > sequence above is correct, once you have killed the Emacs process in > > another window, then it's expected that GDB won't be able to get its > > backtrace. > > So again the (or a) question is, why does this only happen when running > emacs under gdb? If by "this" you mean the backtrace failure, at this point I don't feel we have enough information to answer. But I have not yet read your three other emails. ;-)