From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4235 invoked by alias); 26 Jan 2005 16:26:19 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 3827 invoked from network); 26 Jan 2005 16:25:57 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 26 Jan 2005 16:25:57 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j0QGPuSV012005 for ; Wed, 26 Jan 2005 11:25:56 -0500 Received: from localhost.redhat.com (vpn50-107.rdu.redhat.com [172.16.50.107]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0QGPuO30636; Wed, 26 Jan 2005 11:25:56 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id CD1AB7D79; Wed, 26 Jan 2005 11:25:18 -0500 (EST) Message-ID: <41F7C46D.6040702@gnu.org> Date: Wed, 26 Jan 2005 16:26:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Nick Roberts Cc: gdb@sources.redhat.com Subject: Re: internal-error: insert_step_resume_breakpoint_at_sal References: <16804.1142.136766.593493@farnswood.snap.net.nz> <16874.17961.812024.375273@farnswood.snap.net.nz> <41ED5C15.7070401@gnu.org> <16877.33664.336543.446168@farnswood.snap.net.nz> <41EE82EA.7010803@gnu.org> <16879.224.997596.521183@farnswood.snap.net.nz> <41EFE531.9060605@gnu.org> <16880.27555.756855.225654@farnswood.snap.net.nz> <41F56FCD.6090101@gnu.org> <16887.27939.790997.257717@farnswood.snap.net.nz> In-Reply-To: <16887.27939.790997.257717@farnswood.snap.net.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-01/txt/msg00139.txt.bz2 Nick Roberts wrote: > > Tracking down these sorts of bugs is really important - it makes the > > difference between a toy and a real debugger, and I think your efforts > > have paid off :-) > > > > With the log you provided I've been able to identify one bug - > > back-to-back signals (where the inferior was receiving the next signal > > just as the previous handler returned) would lead to a panic. > > > > I'm about to commit a testcase and fix. > > With todays cvs (GNU gdb 6.3.50.20050126-cvs) I no longer get an internal > error but everything hangs instead. I presume that it is GDB hanging and > not Emacs, as Emacs does not hang at this place when its not running under > debug (I'm only splitting a window). "sick". Is the testcase passing? > However, I don't know how to get a backtrace as sending SIGINT (actually > SIGSTOP with Emacs) interrupts the bottom level process (Emacs in this > case). I can then interrupt the GDB being debugged, but presumably by then > things have changed. You can attach to gdb - $ gdb gdb - and then get a backtrace that way. Anyway, same as before, lets look at a transcript (see the script command) with "set debug infrun 1" (and perhaphs also "set debug target 1" - that one is really verbose). Andrew