Pending Breakpoints

TotalView supports pending breakpoints, useful when setting a breakpoint on code contained in a library that has not yet been loaded into memory.

A pending action point is a breakpoint, barrier point, or evalpoint created with a breakpoint expression that does not yet correspond to any executable code. For example, a common use case is to create a pending function breakpoint with a breakpoint expression that matches the name of a function that will be loaded at runtime via dlopen(), CUDA kernel launch, or anything that dynamically loads executable code.

All four types of breakpoints can be pending (this includes line, function, methods in a class, and virtual function breakpoints). Further, a breakpoint may transition between pending to non-pending as image files are loaded, breakpoint expressions are reevaluated, address blocks are added, and invalid address blocks are nullified.

Set a pending breakpoint either on a function using the At Location dialog, or on a line number in the Source view.

Pending Breakpoints on a Function

When creating a breakpoint on a function using the Action Points > At Location dialog box, you are prompted to choose whether to set the breakpoint as pending if TotalView can't find the function:

To immediately set a pending breakpoint, click Create a pending breakpoint directly in the At Location dialog. This is useful if you are sure that the function name you are entering is correct (even if TotalView can’t find it) because it will be dynamically loaded at runtime. The breakpoint is set as pending:

(Note that, if you click the pending box when TotalView can find the function, it ignores the “Create Pending” request.)

Pending breakpoint prompt

If you didn’t select to create a pending breakpoint and the name you entered was not similar to any existing function, TotalView prompts to set a pending breakpoint.

Pending Breakpoints on a Line Number

Because TotalView “slides” a line number breakpoint to the next valid location (see Sliding Breakpoints ), explicitly setting a line number pending breakpoint is rarely necessary. If, however, you know that there will be code at that spot, you can explicitly set a pending breakpoint in only these ways:

By creating a line number breakpoint at a line near the end of a source file where the following lines have no line number symbols, but where you expect there to be dynamically loaded code at runtime. For example, here is a breakpoint set at line 177 just before the end of a file:

In the At Location dialog box, type the file name and line number of a source file that has not been loaded yet. For example, dynaloaded.c#42 where dynaloaded.c is compiled into a dynamically loaded shared library. TotalView posts a dialog box to confirm, unless "Create a pending breakpoint" is selected.

Conflicting Breakpoints

TotalView can place only one action point on an address. Because the breakpoints you specify are actually expressions, the locations to which these expressions evaluate can overlap or even be the same. Sometimes, and this most often occurs with pending breakpoints in dynamically loaded libraries, TotalView cannot predict when action points will overlap. If they do, TotalView enables only one of the action points and disables all others that evaluate to the same address. The action point that TotalView enables is that with the lowest actionpoint ID. The other overlapping action points are marked as "conflicted" in the Action Points pane and dactions output.