From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1150 invoked by alias); 22 Apr 2008 20:36:26 -0000 Received: (qmail 1142 invoked by uid 22791); 22 Apr 2008 20:36:26 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 22 Apr 2008 20:36:09 +0000 Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id m3MKa3h8015932 for ; Tue, 22 Apr 2008 21:36:03 +0100 Received: from rn-out-0910.google.com (rnbs28.prod.google.com [10.38.95.28]) by zps37.corp.google.com with ESMTP id m3MKX20j006032 for ; Tue, 22 Apr 2008 13:36:02 -0700 Received: by rn-out-0910.google.com with SMTP id s28so1040666rnb.19 for ; Tue, 22 Apr 2008 13:36:02 -0700 (PDT) Received: by 10.114.181.6 with SMTP id d6mr37074waf.50.1208896561517; Tue, 22 Apr 2008 13:36:01 -0700 (PDT) Received: by 10.115.107.18 with HTTP; Tue, 22 Apr 2008 13:36:01 -0700 (PDT) Message-ID: Date: Tue, 22 Apr 2008 21:35:00 -0000 From: "Doug Evans" To: "Paul Pluzhnikov" , gdb-patches@sourceware.org Subject: Re: [RFC] gdb could leave inferior running as a background process In-Reply-To: <20080422195515.GA28506@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <8ac60eac0804220741g6b830620h6f83c627fb00474b@mail.gmail.com> <20080422155548.GA13076@caradoc.them.org> <8ac60eac0804220946r689605e1pd4803c2aea3a9e07@mail.gmail.com> <8ac60eac0804221051p6ad56743g202a6f920d1c6315@mail.gmail.com> <20080422180459.GB20664@caradoc.them.org> <8ac60eac0804221240k4a238445vfba927e22aff93f0@mail.gmail.com> <20080422195515.GA28506@caradoc.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00487.txt.bz2 On Tue, Apr 22, 2008 at 12:55 PM, Daniel Jacobowitz wrote: > > > Where is the warning issued? > > > > #0 warning (string=0x82e9520 "(Internal error: pc 0x%s in read in > > psymtab, but not in symtab.)\n") at > > ../../../google_vendor_src_branch/gdb/gdb-6.8.x/gdb/utils.c:615 > > #1 0x08112c5b in find_pc_sect_symtab (pc=134512896, section=0x0) at > > ../../../google_vendor_src_branch/gdb/gdb-6.8.x/gdb/symtab.c:1984 > > #2 0x08112d79 in find_pc_sect_line (pc=134512896, section=0x0, > > notcurrent=0) at > > ../../../google_vendor_src_branch/gdb/gdb-6.8.x/gdb/symtab.c:2140 > > #3 0x08112fcc in find_pc_line (pc=134512896, notcurrent=0) at > > ../../../google_vendor_src_branch/gdb/gdb-6.8.x/gdb/symtab.c:2262 > > #4 0x08128698 in init_execution_control_state (ecs=0xffffd05c) at > > ../../../google_vendor_src_branch/gdb/gdb-6.8.x/gdb/infrun.c:1128 > > #5 0x08128344 in wait_for_inferior (treat_exec_as_sigtrap=0) at > > ../../../google_vendor_src_branch/gdb/gdb-6.8.x/gdb/infrun.c:1012 > > Ugh. Perhaps we can do this before resuming. It seems like there are multiple places where this can happen. E.g. wait_for_inferior -> handle_inferior_event -> find_pc_partial_function -> target_terminal_ours_for_output.