From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2694 invoked by alias); 26 Jan 2005 21:39:15 -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 2624 invoked from network); 26 Jan 2005 21:39:10 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 26 Jan 2005 21:39:10 -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 j0QLd9FW005029 for ; Wed, 26 Jan 2005 16:39:09 -0500 Received: from localhost.redhat.com (vpn50-7.rdu.redhat.com [172.16.50.7]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0QLd9O32046; Wed, 26 Jan 2005 16:39:09 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 619C27D79; Wed, 26 Jan 2005 16:38:36 -0500 (EST) Message-ID: <41F80DD9.6030503@gnu.org> Date: Wed, 26 Jan 2005 21:39: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> <41F7C46D.6040702@gnu.org> <16888.105.309770.857500@farnswood.snap.net.nz> In-Reply-To: <16888.105.309770.857500@farnswood.snap.net.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-01/txt/msg00145.txt.bz2 Nick Roberts wrote: > > > 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. > > Ah, yes! It just tells me GDB is waiting. Perhaps that was obvious but I had > hoped it would be looping as that would have been a problem that I could have > debugged. > > #0 0x4012e7e9 in wait4 () from /lib/libc.so.6 > #1 0x4012e787 in waitpid () from /lib/libc.so.6 > #2 0x0809b2e2 in child_wait (ptid={pid = -1, lwp = 0, tid = 0}, > ourstatus=0xbffff1d0) at linux-nat.c:1689 > During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at 0x809b2fd. > #3 0x080f98ea in wait_for_inferior () at infrun.c:973 > > > > 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). > > Its attached below. GDB isn't hanging as it spews out more output from infrun > if I move the mouse around in Emacs. Its just not letting Emacs reach the next > statement. This sounds like something was dropped on the floor :-( Looking at the logs, it appears that GDB is continuously receiving and then delivering signals (resume step=0, signal=20) and never getting an oportunity to do a step :-( We're going to need more info, try $ script -c gdb (gdb) file ... (gdb) set debug target 1 (gdb) set debug infrun 1 (gdb) run .. . (gdb) step .. (gdb) quit it will create a transcript file that interleaves the log output and the commands you've typed (and it will be big!). Andrew