4.11 Debugging Forks
On most systems, gdb has no special support for debugging
programs which create additional processes using the
function. When a program forks, gdb will continue to debug the
parent process and the child process will run unimpeded. If you have
set a breakpoint in any code which the child then executes, the child
will get a
SIGTRAP signal which (unless it catches the signal)
will cause it to terminate.
However, if you want to debug the child process there is a workaround
which isn't too painful. Put a call to
sleep in the code which
the child process executes after the fork. It may be useful to sleep
only if a certain environment variable is set, or a certain file exists,
so that the delay need not occur when you don't want to run gdb
on the child. While the child is sleeping, use the
ps program to
get its process ID. Then tell gdb (a new invocation of
gdb if you are also debugging the parent process) to attach to
the child process (see Attach). From that point on you can debug
the child process just like any other process which you attached to.
On some systems, gdb provides support for debugging programs that
create additional processes using the
Currently, the only platforms with this feature are HP-UX (11.x and later
only?) and gnu/Linux (kernel version 2.5.60 and later).
By default, when a program forks, gdb will continue to debug the parent process and the child process will run unimpeded.
- Set the debugger response to a program call of
vfork. A call to
vforkcreates a new process. The mode argument can be:
- The original process is debugged after a fork. The child process runs
unimpeded. This is the default.
- The new process is debugged after a fork. The parent process runs unimpeded.
- Display the current debugger response to a
- Tells gdb whether to detach one of the processes after a fork, or
retain debugger control over them both.
- The child process (or parent process, depending on the value of
follow-fork-mode) will be detached and allowed to run independently. This is the default.
- Both processes will be held under the control of gdb.
One process (child or parent, depending on the value of
follow-fork-mode) is debugged as usual, while the other is held suspended.
- Show whether detach-on-fork mode is on/off.
If you choose to set detach-on-fork mode off, then gdb
will retain control of all forked processes (including nested forks).
You can list the forked processes under the control of gdb by
info inferiors command, and switch from one fork
to another by using the
inferior command (see Debugging Multiple Inferiors and Programs).
To quit debugging one of the forked processes, you can either detach
from it by using the
detach inferior command (allowing it
to run independently), or kill it using the
command. See Debugging Multiple Inferiors and Programs.
If you ask to debug a child process and a
vfork is followed by an
exec, gdb executes the new target up to the first
breakpoint in the new target. If you have a breakpoint set on
main in your original program, the breakpoint will also be set on
the child process's
On some systems, when a child process is spawned by
cannot debug the child or parent until an
exec call completes.
If you issue a
run command to gdb after an
call executes, the new target restarts. To restart the parent
process, use the
file command with the parent executable name
as its argument. By default, after an
exec call executes,
gdb discards the symbols of the previous executable image.
You can change this behaviour with the
Set debugger response to a program call of
execcall replaces the program image of a process.
- gdb creates a new inferior and rebinds the process to this
new inferior. The program the process was running before the
execcall can be restarted afterwards by restarting the original inferior.
(gdb) info inferiors (gdb) info inferior Id Description Executable * 1 <null> prog1 (gdb) run process 12020 is executing new program: prog2 Program exited normally. (gdb) info inferiors Id Description Executable * 2 <null> prog2 1 <null> prog1
- gdb keeps the process bound to the same inferior. The new
executable image replaces the previous executable loaded in the
inferior. Restarting the inferior after the
execcall, with e.g., the
runcommand, restarts the executable the process was running after the
execcall. This is the default mode.
(gdb) info inferiors Id Description Executable * 1 <null> prog1 (gdb) run process 12020 is executing new program: prog2 Program exited normally. (gdb) info inferiors Id Description Executable * 1 <null> prog2
You can use the
catch command to make gdb stop whenever
exec call is made. See Setting Catchpoints.