Next: Checkpoint/Restart, Previous: Threads, Up: Running
On most systems, gdb has no special support for debugging
programs which create additional processes using the fork
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 fork
or vfork
functions.
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.
If you want to follow the child process instead of the parent process,
use the command set follow-fork-mode
.
set follow-fork-mode
modefork
or
vfork
. A call to fork
or vfork
creates a new
process. The mode argument can be:
parent
child
show follow-fork-mode
fork
or vfork
call.
On Linux, if you want to debug both the parent and child processes, use the
command set detach-on-fork
.
set detach-on-fork
modeon
follow-fork-mode
) will be detached and allowed to run
independently. This is the default.
off
follow-fork-mode
) is debugged as usual, while the other
is held suspended.
show detach-on-follow
If you choose to set detach-on-follow 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 using the info forks
command, and switch
from one fork to another by using the fork
command.
info forks
fork
fork-idTo quit debugging one of the forked processes, you can either detach
from it by using the detach fork
command (allowing it to
run independently), or delete (and kill) it using the
delete fork
command.
detach fork
fork-iddelete fork
fork-idIf 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 main
.
When a child process is spawned by vfork
, you cannot debug the
child or parent until an exec
call completes.
If you issue a run
command to gdb after an exec
call executes, the new target restarts. To restart the parent process,
use the file
command with the parent executable name as its
argument.
You can use the catch
command to make gdb stop whenever
a fork
, vfork
, or exec
call is made. See Setting Catchpoints.