Debug a child process


On most systems, GDB has no special support for debugging apps that create additional processes using the fork function. By default, when an app forks, GDB continues to debug the parent process, while the child process runs unimpeded. If you set a breakpoint in any code that the child then executes, the child gets a SIGTRAP signal that causes it to terminate (unless it catches the signal).

  1. To debug the child process, in the code that the child process executes after the fork, include a call to sleep.

    It may be useful to sleep only if a certain environment variable is set, or a certain file exists, so that the delay doesn't occur when you don't want to run GDB on the child.

  2. While the child is sleeping, use the pidin utility to get its process ID.
  3. Instruct GDB to attach to the child process. If you're also debugging the parent process, use a new invocation of GDB.
  4. Debug the child process like any other process that you attach to.

The modes available are:

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. If you want to follow the child process instead of the parent process, use this command. The type can be one of the following:

parent ā€” The original process is debugged after a fork. The child process runs unimpeded. This type is the default type.

child ā€” The new process is debugged after a fork. The parent process runs unimpeded.

ask ā€” The debugger will prompt you for either parent or child.

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 encountered in the new target. If there's a breakpoint set on main in your original program, the breakpoint will also be set on the main function for the child process.

When a child process is spawned by vfork, you can't 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.

For more information about starting your programs and the launch configuration options, see the Create and run a launch configuration chapter.

After building a debug-enabled executable, your next step is to create a launch configuration for that executable so you can run and debug it:

To launch your program:
  1. From the main menu, select Debug As > Debug Configurations (alternatively, you can select Run > Run Configurationsā€¦ to open the dialog directly). You'll be prompted to select a configuration type for new projects.
    The launch configuration dialog appears.
  2. Create a launch configuration as you normally would, but don't click OK.
    For information about creating a launch configuration, see Launch configuration types.
  3. Select the Debugger tab.

    Debugger tab

  4. Optional: For GDB, select Verbose console mode to see all of the commands sent to GDB, and all of the responses returned from GDB.
  5. Optional: Set Use full path to set breakpoints to set breakpoints if you have many files with the same base name in the project. When file names are identical but their paths are different, setting this option ensures that breakpoints are set for the appropriate file, as expected.

    This feature works only when you use gcc 4.6 or higher and gdb 7.3 or higher.

  6. Click Apply.
  7. Click Debug.

The IDE changes to the Debug perspective.

By default:

  • The IDE automatically changes to the Debug perspective when you debug a program. If the default is no longer set, or if you wish to change to a different perspective when you debug, see the Run and debug subsequent times section in the Launch Configurations Reference chapter.
  • The IDE removes terminated debugging sessions from the Debug view when you launch a new session. This frees resources on your development host and your debugging target. You can retain the completed debug sessions by deselecting the Remove terminated launches when a new launch is created box in the Run/Debug > Launching pane of the Preferences dialog.

Last modified: 2013-12-21

comments powered by Disqus