From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23737 invoked by alias); 14 Nov 2007 10:00:11 -0000 Received: (qmail 23681 invoked by uid 22791); 14 Nov 2007 10:00:10 -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 10:00:08 +0000 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1IsF2R-0005AA-1d for gdb@sources.redhat.com; Wed, 14 Nov 2007 10:00:03 +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 10:00:03 +0000 Received: from Stephen.Berman by i577bc647.versanet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Nov 2007 10:00:03 +0000 To: gdb@sources.redhat.com From: Stephen Berman Subject: Re: GDB cannot access memory after Emacs abort Date: Wed, 14 Nov 2007 10:00:00 -0000 Message-ID: <874pfpi2de.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> <1194995493.12695.38.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/msg00130.txt.bz2 On Tue, 13 Nov 2007 15:26:33 -0800 Dan Nicolaescu wrote: > Michael Snyder writes: [...] > > 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. Indeed it does, thanks. (I actually combined your suggestion to use Emacs's multi-tty capability with Michael Snyder's to attach the emacs process to gdb: I did the latter from within the Emacs client. This had the advantage over running gdb directly from the shell that I could copy and paste the backtrace from the shell buffer to my followup buffer in Gnus.) (Before reading your post I had tried sort of the inverse strategy: I started emacs under gdb from a virtual console, switched to X, invoked emacsclient -c from an X terminal and induced the abort. However, when I switched back to the virtual console the gdb process was dead. In hindsight this was obviously a flawed strategy, but I'm still learning how to use the multi-tty capability. When will the doc be ready? ;-) ) Steve Berman