From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27487 invoked by alias); 26 Jan 2005 10:19:53 -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 27362 invoked from network); 26 Jan 2005 10:19:41 -0000 Received: from unknown (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org with SMTP; 26 Jan 2005 10:19:41 -0000 Received: from farnswood.snap.net.nz (p1-tnt2.snap.net.nz [202.124.108.1]) by viper.snap.net.nz (Postfix) with ESMTP id 576CE2888F8; Wed, 26 Jan 2005 23:19:38 +1300 (NZDT) Received: by farnswood.snap.net.nz (Postfix, from userid 501) id 8C25C628AE; Wed, 26 Jan 2005 10:12:52 +0000 (GMT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16887.27939.790997.257717@farnswood.snap.net.nz> Date: Wed, 26 Jan 2005 10:19:00 -0000 To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: internal-error: insert_step_resume_breakpoint_at_sal In-Reply-To: <41F56FCD.6090101@gnu.org> 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> X-SW-Source: 2005-01/txt/msg00126.txt.bz2 > 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). 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. Nick