|C H A P T E R 12|
Debugging Child Processes
This chapter describes how to debug a child process. dbx has several facilities to help you debug processes that create children using the fork (2) and exec (2) functions.
This chapter is organized into the following sections:
You can attach to a running child process in one of the following ways.
You can substitute program_name with the name - (minus sign), so that dbx finds the executable associated with the given process ID (process_id). After using a -, a subsequent run command or rerun command does not work because dbx does not know the full path name of the executable.
You can also attach to a running child process using the Debugger window in the Sun Studio IDE. (See "Attaching to a Process" in the dbx Debugger helpset in the IDE online help.)
If a child process executes a new program using the exec(2)function or one of its variations, the process id does not change, but the process image does. dbx automatically takes note of a call to the exec() function and does an implicit reload of the newly executed program.
The original name of the executable is saved in $oprog. To return to it, use debug $oprog.
If a child process calls the vfork(), fork(1), or fork(2) function, the process id changes, but the process image stays the same. Depending on how the dbx environment variable follow_fork_mode is set, dbx does one of the following.
You are prompted to choose parent, child, both, or stop to investigate whenever dbx detects a fork. If you choose stop, you can examine the state of the program, then type cont to continue; you will be prompted to select which way to proceed.
All breakpoints and other events are deleted for any exec() or fork() process. You can override the deletion for forked processes by setting the dbx environment variable follow_fork_inherit to on, or make the events permanent using the -perm eventspec modifier. For more information on using event specification modifiers, see Appendix B.