6.10. Debugging programs with multiple processes
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 (refer to Section 6.7 Debugging an already-running process). From that point on you can debug
the child process just like any other process which you attached to.
On HP-UX (11.x and later only?), gdb provides support for
debugging programs that create additional processes using the
fork or vfork function.
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 mode
Set the debugger response to a program call of fork or
vfork. A call to fork or vfork creates a new
process. The mode can be:
- parent
The original process is debugged after a fork. The child process runs
unimpeded. This is the default.
- child
The new process is debugged after a fork. The parent process runs
unimpeded.
- ask
The debugger will ask for one of the above choices.
- show follow-fork-mode
Display the current debugger response to a fork or vfork call.
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 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.
Refer to Section 7.1.3 Setting catchpoints.
