From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15213 invoked by alias); 24 Jan 2005 21:59:52 -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 15187 invoked from network); 24 Jan 2005 21:59:48 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 24 Jan 2005 21:59:48 -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 j0OLxl8A027779 for ; Mon, 24 Jan 2005 16:59:47 -0500 Received: from localhost.redhat.com (vpn50-31.rdu.redhat.com [172.16.50.31]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0OLxlO09000; Mon, 24 Jan 2005 16:59:47 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 1ED6B7D79; Mon, 24 Jan 2005 16:59:43 -0500 (EST) Message-ID: <41F56FCD.6090101@gnu.org> Date: Mon, 24 Jan 2005 21:59: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> In-Reply-To: <16880.27555.756855.225654@farnswood.snap.net.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-01/txt/msg00121.txt.bz2 Nick Roberts wrote: > > What's at $pc (where PC is 0x4012e7e9 or 0x80850d5), symtab==0 indicates > > a symtab lookup failure. > > See my earlier message to Dave Korn. > > > > > Can you capture the output from "set debug infrun 1"? It should help. > > > > > > See below. I can send the full transcript if necessary. > > > > How much more? > > Well its only the stuff before I type "next" i.e. Emacs starting up and > lots of: > > ... > infrun: TARGET_WAITKIND_STOPPED > infrun: stop_pc = 0x4012e7e9 > infrun: random signal 20 > infrun: resume (step=0, signal=20) > infrun: prepare_to_wait > infrun: infwait_normal_state > infrun: TARGET_WAITKIND_STOPPED > infrun: stop_pc = 0x4012e7e9 > infrun: random signal 20 > ... > > > There appears to be stuff missing here, the output should contain > > something like: > > > > resume(step=1, signal=0) > > resume(step=0, signal=0) > > > > as GDB single-steps the thread off breakpoint 3. The PC should be near > > or at 0x80850d5 found in the below. > > Thats much earlier. I attach the full transcript below. > > Maybe its too hard to debug over the Internet as I don't understand the > internals well enough. It doesn't seem to be causing a problem for anybody > else and I can get round it in the way I suggested in my first message. 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. thanks, Andrew