From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-30204-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 8584 invoked by alias); 13 Nov 2007 23:28:48 -0000
Received: (qmail 8576 invoked by uid 22791); 13 Nov 2007 23:28:48 -0000
X-Spam-Check-By: sourceware.org
Received: from oogie-boogie.ics.uci.edu (HELO oogie-boogie.ics.uci.edu) (128.195.1.41)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 13 Nov 2007 23:28:46 +0000
Received: from mothra.ics.uci.edu (mothra.ics.uci.edu [128.195.6.93]) 	by oogie-boogie.ics.uci.edu (8.13.6/8.13.6) with ESMTP id lADNQXCE017358; 	Tue, 13 Nov 2007 15:26:38 -0800 (PST)
Date: Tue, 13 Nov 2007 23:28:00 -0000
Message-Id: <ur9k5olral2.fsf@mothra.ics.uci.edu>
From: Dan Nicolaescu <dann@ics.uci.edu>
To: Michael Snyder <msnyder@specifix.com>
Cc: Stephen Berman <Stephen.Berman@gmx.net>, gdb@sources.redhat.com
Subject: Re: GDB cannot access memory after Emacs abort
In-Reply-To: <1194995493.12695.38.camel@localhost.localdomain> (Michael 	Snyder's message of "Tue, 13 Nov 2007 15:11:33 -0800")
References: <87r6j6rvn3.fsf@escher.local.home> 	<87hcjtllau.fsf@escher.local.home> 	<1194763094.16917.278.camel@localhost.localdomain> 	<ufxzdp6p4.fsf@gnu.org> <87ir48gzet.fsf@escher.local.home> 	<1194844555.16917.319.camel@localhost.localdomain> 	<87fxz9dbks.fsf@escher.local.home> 	<1194995493.12695.38.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-ICS-MailScanner: Found to be clean
X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.363, 	required 5, autolearn=disabled, ALL_TRUSTED -1.44, TW_XB 0.08)
X-ICS-MailScanner-From: dann@ics.uci.edu
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2007-11/txt/msg00116.txt.bz2

Michael Snyder <msnyder@specifix.com> writes:

  > On Tue, 2007-11-13 at 23:28 +0100, Stephen Berman wrote:
  > > On Sun, 11 Nov 2007 21:15:55 -0800 Michael Snyder <msnyder@specifix.com> wrote:
  > > 
  > > > On Mon, 2007-11-12 at 00:01 +0100, Stephen Berman wrote:
  > > >> On Sun, 11 Nov 2007 09:44:23 +0200 Eli Zaretskii <eliz@gnu.org> 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 <abort+6>:    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.

You can do that by using the power of emacs :-)

Run emacs from CVS
M-x server-start RET
M-x gdb
from this gdb start another emacs session and do whatever you need to
induce the crash (just make sure that in the second instance of emacs
you don't run `server-start')

switch to a console and run 
emacsclient -t 

this should connect to the first emacs instance and give you access to
gdb, you can run all the gdb commands there ... 

Hope this helps.