When you’re debugging message-passing and other multi-process programs, it is usually easier to understand the program’s behavior if you change the default stopping action of breakpoints and barrier breakpoints. By default, when one process in a multi-process program hits a breakpoint, TotalView stops all other processes.
To change the default stopping action of breakpoints and barrier breakpoints, you can set debugger preferences. The online Help contains information on these preference. These preferences tell TotalView whether to continue to run when a process or thread hits the breakpoint.
TotalView has two features that make it easier to get all of the processes in a multi-process program synchronized and executing a line of code. Process barrier breakpoints and the process hold/release features work together to help you control the execution of your processes. See "Setting Barrier Points".
The Process Window Group > Run To command is a special stepping command. It lets you run a group of processes to a selected source line or instruction. See "Stepping (Part I)".
Using Group Commands
Group commands are often more useful than process commands.
It is often more useful to use theGroup > Go command to restart the whole application instead of the Process > Go command.
If you use a process-level single-stepping command in a multi-process program, TotalView may appear to hang (it continuously displays the watch cursor). If you single-step a process over a statement that can’t complete without allowing another process to run, and that process is stopped, the stepping process appears to hang. This can occur, for example, when you try to single-step a process over a communication operation that cannot complete without the participation of another process. When this happens, you can abort the single-step operation by selecting Cancel in the Waiting for Command to Complete Window that TotalView displays. As an alternative, consider using a group-level single-step command.
CLI: Type Ctrl+C
NOTE >> Rogue Wave receives many bug reports on hung processes, usually because one process is waiting for another. Using the Group debugging commands almost always solves this problem.