This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: "run", and executable file/symtab association?
- From: Daniel Jacobowitz <drow at false dot org>
- To: Randolph Chung <tausq at debian dot org>
- Cc: gdb at sources dot redhat dot com
- Date: Tue, 14 Feb 2006 22:09:09 -0500
- Subject: Re: "run", and executable file/symtab association?
- References: <dsu1q7$93m$1@sea.gmane.org>
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