From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8936 invoked by alias); 12 Nov 2007 05:24:51 -0000 Received: (qmail 8927 invoked by uid 22791); 12 Nov 2007 05:24:51 -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; Mon, 12 Nov 2007 05:24:49 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id A69723BE6F; Sun, 11 Nov 2007 21:06:35 -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: <87ir48gzet.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> Content-Type: text/plain Date: Mon, 12 Nov 2007 05:24:00 -0000 Message-Id: <1194844555.16917.319.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/msg00092.txt.bz2 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 > > > > Stack overflow, maybe? > > Due to an infinite loop in Emacs? (I don't know if the bug I reported > caused this, maybe Jan D. can answer that.) But as I mentioned in my > other followup, I've never experienced an infinite loop in Emacs that > locked up X. If it was due to a stack overflow, does that mean GDB is > above suspicion in this case? No, it just means we don't yet have enough information to diagnose it. Stack overflow could potentially produce a state that was too corrupt for gdb to decypher, but we don't know yet if that's the case. Now that I know that the target is x86-linux, I can reasonably speculate that 0xbfd6836c looks like a stack address, and 0x8321b6c looks like a code or data address. But so far those are only guesses, and it isn't yet clear why gdb would be unable to access memory at those addresses. I wonder -- after the above happens, what do you get if you type the following at the (gdb) prompt: x /i $eip 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. If not, then some child memory is accessable and some is not (which is not entirely surprising) -- and the question becomes, why is gdb trying to read from memory that is not accessable?