TotalView Users Guide - CI Wiki

Why breakpoints
don’t work
(part 1)
Why breakpoints
don’t work
(part 2)
Why single
stepping doesn’t
work
Why Barrier
points work
Using Barrier Points
Manipulating Processes and Threads
Held/Release State What Can Be Run Using Process > Go
Go to the Threads menu. The button next to the Hold
command isn’t selected. This is because the thread hold state
is independent from the process hold state.
Select it. The circle indicates that thread 1 is held. At this
time, there are two different holds on thread 1. One is at the
process level; the other is at thread level.
Nothing will run when you select Process > Go.
Select the Process > Hold command.
Select Process > Go. The second and third threads run.
Select Process > Release Threads. This releases the hold
placed on the first thread by the Thread > Hold command.
After you select Process > Go, all threads run.
Because threads and processes are often executing different instructions,
keeping threads and processes together is difficult. The best strategy is to
define places where the program can run freely and places where you need
control. This is where barrier points come in.
To keep things simple, this section only discusses multi-process programs.
You can do the same types of operations when debugging multi-threaded
programs.
If you set a breakpoint that stops all processes when it is hit and you let
your processes run using the Group > Go command, you can get lucky and
all of your threads will be at the breakpoint. What’s more likely is that some
processes won’t have reached the breakpoint and TotalView will stop them
wherever they happen to be. To get your processes synchronized, you need
to find out which ones didn’t get there and then individually get them to
the breakpoint using the Process > Go command. You can’t use the
Group > Go command since this also runs the processes stopped at the
breakpoint.
If you set the breakpoint’s property so that only the process hitting the
breakpoint stops, you have a better chance of getting processes there.
However, you should not have other breakpoints between where the program
is currently at and this breakpoint. If processes hit these breakpoints,
you are once again left running individual processes to the breakpoint.
Single stepping is just too tedious if you have a long way to go to get to
your synchronization point, and stepping just won’t work if your processes
don’t execute exactly the same code.
If you use a barrier point, you can use the Group > Go command as many
times as it takes to get all of your processes to the barrier, and you won’t
have to worry about a process running past the barrier.
TotalView Users Guide: version 8.7 233