From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14371 invoked by alias); 15 Feb 2006 03:09:14 -0000 Received: (qmail 14362 invoked by uid 22791); 15 Feb 2006 03:09:13 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 15 Feb 2006 03:09:12 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1F9D2T-0002Hc-Pu; Tue, 14 Feb 2006 22:09:09 -0500 Date: Wed, 15 Feb 2006 03:09:00 -0000 From: Daniel Jacobowitz To: Randolph Chung Cc: gdb@sources.redhat.com Subject: Re: "run", and executable file/symtab association? Message-ID: <20060215030909.GB8700@nevyn.them.org> Mail-Followup-To: Randolph Chung , gdb@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00153.txt.bz2 On Wed, Feb 15, 2006 at 09:57:31AM +0800, Randolph Chung wrote: > I've been debugging the new checkpoint feature on hppa-linux, and came > across an unexpected "feature" of gdb. > > See the transcript below - when the program being debugged dies, I > expect to be able to restart it with "run", but gdb reports an error. > Interestingly, I can still set breakpoints so gdb has not completely > disassociated the program. Looks to me like a bug, specifically here: > The code that outputs the error is corefile.c:get_exec_file(), where > exec_bfd was previously set to NULL by a call to exec_close > > Breakpoint 3, exec_close (quitting=0) at ../../gdb-cvs/gdb/exec.c:103 > 103 int need_symtab_cleanup = 0; > (top-gdb) bt > #0 exec_close (quitting=0) at ../../gdb-cvs/gdb/exec.c:103 > #1 0x0016c888 in target_close (targ=0x3a251c, quitting=0) > at ../../gdb-cvs/gdb/target.c:1881 > #2 0x00169a9c in pop_target () at ../../gdb-cvs/gdb/target.c:745 > #3 0x00073cb0 in kill_inferior () at ../../gdb-cvs/gdb/linux-nat.c:619 > #4 0x0012957c in kill_if_already_running (from_tty=1) > at ../../gdb-cvs/gdb/infcmd.c:449 > #5 0x001295d0 in run_command_1 (args=0x0, from_tty=1, tbreak_at_main=0) > at ../../gdb-cvs/gdb/infcmd.c:468 > #6 0x001298f0 in run_command (args=0x0, from_tty=1) > at ../../gdb-cvs/gdb/infcmd.c:559 > > I haven't debugged this more yet - is this considered "works as > designed"? or is it a bug? If kill_inferior calls pop_target it'd better be expecting to close a native target, not the exec target further down the stack. This looks like a bug in the checkpoint code somewhere. Ugh, the bits in kill_inferior are a little scary. First thing to do: figure out what's on the target stack (follow current_target.beneath), and why it's got execution if it's popping exec_close. -- Daniel Jacobowitz CodeSourcery