"run", and executable file/symtab association?

"run", and executable file/symtab association?

[Randolph Chung]

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.

tausq@riot:~/gdb/build/gdb/testsuite$ ../gdb gdb.base/checkpoint
GNU gdb 6.4.50.20060214-cvs
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "hppa-linux"...Using host libthread_db
library "/lib/libthread_db.so.1".

(gdb) b 50
Breakpoint 1 at 0x10810: file
../../../gdb-cvs/gdb/testsuite/gdb.base/checkpoint.c, line 50.
(gdb) run
Starting program: /home/tausq/gdb/build/gdb/testsuite/gdb.base/checkpoint

Breakpoint 1, main ()
    at ../../../gdb-cvs/gdb/testsuite/gdb.base/checkpoint.c:50
50              lines++;        /* breakpoint 1 */
(gdb) checkpoint
checkpoint: fork returned pid 5094.
(gdb) restart 1

Program received signal SIGTRAP, Trace/breakpoint trap.
0xc05903c0 in ?? ()
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (lseek) will be
abandoned.
(gdb) delete
Delete all breakpoints? (y or n) y
(gdb) b 55

Breakpoint 2 at 0x10854: file
../../../gdb-cvs/gdb/testsuite/gdb.base/checkpoint.c, line 55.
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program:
No executable file specified.
Use the "file" or "exec-file" command.
(gdb)


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?

randolph

Re: "run", and executable file/symtab association?

[Daniel Jacobowitz]

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

Re: "run", and executable file/symtab association?

[Randolph Chung]

> 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.

The target stack looks like:

(top-gdb) print current_target->to_shortname
$2 = 0x334298 "child"
(top-gdb) print current_target->beneath->to_shortname
$3 = 0x334298 "child"
(top-gdb) print current_target->beneath->beneath->to_shortname
$4 = 0x2d7d6c "exec"
(top-gdb) print current_target->beneath->beneath->beneath->to_shortname
$5 = 0x312614 "None"

And to_close is:
(top-gdb) print current_target->to_close
$6 = (void (*)(int)) @0x38465a: 0x47954 <exec_close>

kill_inferior() says:

   /* First cut -- let's crudely do everything inline.  */
   if (forks_exist_p ())
     {
       linux_fork_killall ();
       pop_target ();
       generic_mourn_inferior ();
     }
   else
     {
...
     }

I don't pretend to understand this code and why if there are forks, we 
should be popping the target to kill everything.

Michael Snyder added/changed this when he checked in the checkpoint 
code, perhaps he can comment?

randolph

Re: "run", and executable file/symtab association?

[Daniel Jacobowitz]

On Sat, Feb 18, 2006 at 05:53:56PM +0800, Randolph Chung wrote:
> >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.
> 
> The target stack looks like:
> 
> (top-gdb) print current_target->to_shortname
> $2 = 0x334298 "child"
> (top-gdb) print current_target->beneath->to_shortname
> $3 = 0x334298 "child"
> (top-gdb) print current_target->beneath->beneath->to_shortname
> $4 = 0x2d7d6c "exec"
> (top-gdb) print current_target->beneath->beneath->beneath->to_shortname
> $5 = 0x312614 "None"
> 
> And to_close is:
> (top-gdb) print current_target->to_close
> $6 = (void (*)(int)) @0x38465a: 0x47954 <exec_close>

pop_target calls current_target->to_close.  I am suspecting that it
should call target_stack->to_close instead.

> I don't pretend to understand this code and why if there are forks, we 
> should be popping the target to kill everything.

I don't either.

-- 
Daniel Jacobowitz
CodeSourcery

Re: "run", and executable file/symtab association?

[Randolph Chung]

> pop_target calls current_target->to_close.  I am suspecting that it
> should call target_stack->to_close instead.

hrm, target_stack is "child", and its to_close method is NULL. 
target_stack->beneath is "exec" and its to_close is exec_close...

>>I don't pretend to understand this code and why if there are forks, we 
>>should be popping the target to kill everything.
> I don't either.

ok, I'll wait for Michael to respond :)

randolph

Re: "run", and executable file/symtab association?

[Daniel Jacobowitz]

On Sun, Feb 19, 2006 at 01:28:13AM +0800, Randolph Chung wrote:
> >pop_target calls current_target->to_close.  I am suspecting that it
> >should call target_stack->to_close instead.
> 
> hrm, target_stack is "child", and its to_close method is NULL. 
> target_stack->beneath is "exec" and its to_close is exec_close...

Right; but we're not closing exec.  Take a look at target_close()
which does nothing if the method is NULL.

-- 
Daniel Jacobowitz
CodeSourcery

Re: "run", and executable file/symtab association?

[Michael Snyder]

Daniel Jacobowitz wrote:
> On Sat, Feb 18, 2006 at 05:53:56PM +0800, Randolph Chung wrote:
> 
>>>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.
>>
>>The target stack looks like:
>>
>>(top-gdb) print current_target->to_shortname
>>$2 = 0x334298 "child"
>>(top-gdb) print current_target->beneath->to_shortname
>>$3 = 0x334298 "child"
>>(top-gdb) print current_target->beneath->beneath->to_shortname
>>$4 = 0x2d7d6c "exec"
>>(top-gdb) print current_target->beneath->beneath->beneath->to_shortname
>>$5 = 0x312614 "None"
>>
>>And to_close is:
>>(top-gdb) print current_target->to_close
>>$6 = (void (*)(int)) @0x38465a: 0x47954 <exec_close>
> 
> pop_target calls current_target->to_close.  I am suspecting that it
> should call target_stack->to_close instead.
> 
>>I don't pretend to understand this code and why if there are forks, we 
>>should be popping the target to kill everything.
> 
> I don't either.

Hey guys,

Message received and acknowledged.  I'm on vacation this week.
Is it urgent?

Michael

Re: "run", and executable file/symtab association?

[Randolph Chung]

> Message received and acknowledged.  I'm on vacation this week.
> Is it urgent?

A week or so won't make a difference, have a good vacation and we can 
look at this again when you get back :)

randolph