C H A P T E R 13 |
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 Sun WorkShop Debugging window. (See "Attaching to a Running Process" in the Using the Debugging window section of the Sun WorkShop 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.
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.
Copyright © 2004, Sun Microsystems, Inc. All rights reserved.