4.10 Debugging Programs with Multiple Processes

On most systems, No value for GDBN has no special support for debugging programs which create additional processes using the fork function. When a program forks, No value for GDBN 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 No value for GDBN on the child. While the child is sleeping, use the ps program to get its process ID. Then tell No value for GDBN (a new invocation of No value for GDBN if you are also debugging the parent process) to attach to the child process (see section 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 some systems, No value for GDBN 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, No value for GDBN 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 argument 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.

show follow-fork-mode

Display the current debugger response to a 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 mode

Tells gdb whether to detach one of the processes after a fork, or retain debugger control over them both.

on

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.

off

Both processes will be held under the control of No value for GDBN. One process (child or parent, depending on the value of follow-fork-mode) is debugged as usual, while the other is held suspended.

show detach-on-follow

Show whether detach-on-follow mode is on/off.

If you choose to set detach-on-follow mode off, then No value for GDBN will retain control of all forked processes (including nested forks). You can list the forked processes under the control of No value for GDBN by using the info forks command, and switch from one fork to another by using the fork command.

info forks

Print a list of all forked processes under the control of No value for GDBN. The listing will include a fork id, a process id, and the current position (program counter) of the process.

fork fork-id

Make fork number fork-id the current process. The argument fork-id is the internal fork number assigned by No value for GDBN, as shown in the first field of the ‘info forks’ display.

To 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-id

Detach from the process identified by No value for GDBN fork number fork-id, and remove it from the fork list. The process will be allowed to run independently.

delete fork fork-id

Kill the process identified by No value for GDBN fork number fork-id, and remove it from the fork list.

If you ask to debug a child process and a vfork is followed by an exec, No value for GDBN 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 No value for GDBN 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 No value for GDBN stop whenever a fork, vfork, or exec call is made. See section Setting Catchpoints.