Debugging a child process

By default, when a process creates another process, GDB doesn't follow the execution of the child process.
You must attach another instance of the debugger to this new process; this action lets you debug the parent and child concurrently.

The best strategy for debugging a child process is to make the child send a SIGSTOP signal to itself right
after the fork() statement that creates it.
This stops the process so you can attach the debugger and manually resume execution or step through the child's code.

To debug a child process concurrently with its parent:

Set a breakpoint in the parent code path right after the fork() statement.

In the launch bar, select the appropriate project and launch target, and the Debug launch mode.

Click the Debug button ().

The IDE switches to the Debug perspective, which displays the source code being traced and the current variables and
breakpoints. If necessary, the IDE builds the application and uploads the binary to the target. Then, it runs the
binary and GDB, which it attaches to the binary.

If GDB stops on startup, press F8 or click the Resume button at the top of the Debug
view to continue execution.

The program runs until the breakpoint just after the fork() call in the parent code path.
The child process will now be running and if you added a line to send the SIGSTOP signal, it will be
stopped at that line.

Learn the ID of the child process.

In the Variables view, you can examine the variable that stores the fork()
result. Because GDB is following the parent code path, this variable shows the PID of the new child.

You can also switch to the QNX System Information perspective and in the System Summary view,
find the processes with same name as the binary you're running.
The child process will most likely have a PID that's a slightly higher number than that of the parent.

In the Launch Mode dropdown, select Attach.

Click the Attach button
().

The IDE opens the Select Process window, which lists the processes with the same name
as the binary specified in the
launch configuration settings.

Click the entry for the child process you want to debug, then click OK.

The IDE runs another GDB instance, attaches it to the child process, and displays an entry for this process in the
Debug view. If the child's main thread has been stopped by the SIGSTOP signal,
the thread label contains the word STOPPED.
You can start debugging the child code by pressing F7 or clicking the Step Return button at the top of
the view, once to step out of the SignalKill() call and then again to step out of
kill() and back into the main thread.

You can now debug the child and parent processes concurrently, by alternating between the different sessions in
the Debug view. When you click a session entry, you access the GDB instance attached to the
corresponding process and any debugging actions you then perform (e.g., resuming execution, stepping through code)
are applied to that process.
This design lets you attach GDB instances to several child processes and debug all of them concurrently.

Following execution into a child process

When a program executes a fork() statement, GDB by default follows the parent code path.
To make GDB follow the child code path instead, you must preset the right mode in the gdb utility.

In the Debug tab of the launch configuration, you can name a command file that GDB
executes whenever it starts up. In this file, you can preset the child-following mode using this command:

set follow-fork-mode child

This strategy is handy when you always want to follow the code path of the child instead of the parent. If you want to
debug into the child only occasionally, you can manually set this mode before the child process gets created.
To do so, you must first verify that GDB is configured to stop on startup, so you have time to issue the necessary
gdb command.

To manually follow execution into the child:

Select the project, target, and Debug launch mode in the launch bar, then click the Debug button.

The IDE switches to the Debug perspective, starts GDB, and attaches it to the application process. GDB stops the
application on startup, at the first line in main() (if you use default settings).

Click the Console view to interact with the gdb utility.

In this view, the IDE should show the gdb output, as indicated by the utility's path given in
the view header. If you don't see the gdb output initially, click the
Display Selected Console button () in the upper right area
and select the gdb binary entry.

Enter the command set follow-fork-mode child.

You can confirm this setting by typing show follow-fork-mode;
gdb then displays this message:

Debugger response to a program call of fork or vfork is "child".

Press F8 or click the Resume button in the Debug view to continue execution.

GDB lets the application run and create the child process.
When this happens, GDB follows execution into the child when the program executes the fork() call.