From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4686 invoked by alias); 13 Nov 2007 23:20:54 -0000 Received: (qmail 4678 invoked by uid 22791); 13 Nov 2007 23:20:54 -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:20:51 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 7B2FB3C071; Tue, 13 Nov 2007 15:02:13 -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: <87fxz9dbks.fsf@escher.local.home> References: <87r6j6rvn3.fsf@escher.local.home> <87hcjtllau.fsf@escher.local.home> <1194763094.16917.278.camel@localhost.localdomain> <87ir48gzet.fsf@escher.local.home> <1194844555.16917.319.camel@localhost.localdomain> <87fxz9dbks.fsf@escher.local.home> Content-Type: text/plain Date: Tue, 13 Nov 2007 23:20:00 -0000 Message-Id: <1194995493.12695.38.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/msg00114.txt.bz2 On Tue, 2007-11-13 at 23:28 +0100, Stephen Berman wrote: > On Sun, 11 Nov 2007 21:15:55 -0800 Michael Snyder wrote: > > > On Mon, 2007-11-12 at 00:01 +0100, Stephen Berman wrote: > >> On Sun, 11 Nov 2007 09:44:23 +0200 Eli Zaretskii wrote: > >> > >> > the upshot of all this is that `bt' doesn't > >> > work, as shown below: > >> > > >> >> > > (gdb) bt > >> >> > > #0 abort () at emacs.c:431 > >> >> > > Cannot access memory at address 0xbfd6836c > >> >> > > Cannot access memory at address 0x8321b6c > >> > > [...] > > I wonder -- after the above happens, what do you get if you > > type the following at the (gdb) prompt: > > > > x /i $eip > > After the abort occurs, the desktop locks up, I switch to a virtual tty > and kill -9 the emacs process, releasing the desktop, then type what you > said at the gdb prompt and get this: > > 0x80f9e56 : Cannot access memory at address 0x80f9e56 Oh yes. I understand that now, thanks. What we need, I guess, is to get back into control of the gdb without killing the emacs. Otherwise it is kind of hard to debug this gdb problem further. > > If you get the same error (Cannot access memory at ...), > > then perhaps gdb has lost contact with the child process > > entirely, and cannot access *any* memory. > > Yes, this is also what Jim Blandy surmised. Well, as I now understand, that's because you killed the emacs. > But, as I ask in my > response to Blandy, why does the desktop lock up only happen when the > emacs abort is induced while running under gdb? I believe this is now well understood, and not a gdb problem. In a nutshell, your emacs process has a lock on a shared resource (the X keyboard-and-mouse "focus"). It is intended to keep that lock only briefly, but while in posession of the lock, it aborts. Normally an abort would result in the freeing of the lock, but since gdb stops the emacs process from exiting, the lock is not freed, resulting in a deadlock when some other process (eg. xterm) needs the lock. This is a problem, but a normal and predictable one. GDB cannot tell when a debugged process is in posession of a lock that will cause other processes to deadlock, and it has no way of freeing such locks. This could happen with any shared, lockable resource.