Using SoftBench Debugger

Debugging Forked Processes

Debugging Forked Processes

Some applications use the fork(2) command to create a child process. When a program calls fork, a second process is created that is an exact "clone" of the first process. The only difference between the two processes is the return value of the fork call; this tells each process whether it is the "parent" or "child" process.

Since the fork call results in two processes, you must decide which process or processes you want to debug:

Debug Parent

Your existing debugger session stays attached to the

 

parent process. The child process continues from the

 

fork call.

Debug Child

Your existing debugger session attaches to the child

 

process. The parent process continues from the fork

 

call.

Debug Both

Both processes are debugged. SoftBench spawns a

 

second debugger to debug the new process.

Choose one of the above options under "Options: Fork Behavior …". This selection affects all future fork calls. See “Attaching the Debugger to a Running Program” on page 222 if your program has already forked and the process you want to debug is not loaded in the debugger.

vfork(2) operates slightly differently. vfork is a "light-weight" fork. Most programs exec a new executable in the child process immediately after returning from the fork. When fork "clones" the parent process, it copies the parent's data space, and the exec immediately discards it. This can be very inefficient if the parent has a large data space.

Instead of creating an exact copy of the parent process, vfork creates a child process that shares the parent's data space. The parent is effectively suspended, and the child is treated as a thread of the parent, until the child execs another program or exits. If the child calls exec, it is then treated as a new process, and the debug behavior above takes effect.

Chapter 7

219