JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Studio 12.3: Debugging a Program With dbx     Oracle Solaris Studio 12.3 Information Library
search filter icon
search icon

Document Information


1.  Getting Started With dbx

2.  Starting dbx

3.  Customizing dbx

4.  Viewing and Navigating To Code

5.  Controlling Program Execution

6.  Setting Breakpoints and Traces

Setting Breakpoints

Setting a stop Breakpoint at a Line of Source Code

Setting a stop Breakpoint in a Function

Setting Multiple Breaks in C++ Programs

Setting Breakpoints in Member Functions of Different Classes

Setting Breakpoints in All Member Functions of a Class

Setting Multiple Breakpoints in Nonmember Functions

Setting Breakpoints in Objects

Setting Data Change Breakpoints

Stopping Execution When an Address Is Accessed

Stopping Execution When Variables Change

Stopping Execution on a Condition

Setting Filters on Breakpoints

Using the Return Value of a Function Call as a Filter

Setting Data Change Breakpoints on Local Variables

Using a Filter With a Conditional Event

Tracing Execution

Setting a Trace

Controlling the Speed of a Trace

Directing Trace Output to a File

Setting a when Breakpoint at a Line

Setting Breakpoints in Dynamically Loaded Libraries

Listing and Clearing Breakpoints

Listing Breakpoints and Traces

Deleting Specific Breakpoints Using Handler ID Numbers

Enabling and Disabling Breakpoints

Efficiency Considerations

7.  Using the Call Stack

8.  Evaluating and Displaying Data

9.  Using Runtime Checking

10.  Fixing and Continuing

11.  Debugging Multithreaded Applications

12.  Debugging Child Processes

13.  Debugging OpenMP Programs

14.  Working With Signals

15.  Debugging C++ With dbx

16.  Debugging Fortran Using dbx

17.  Debugging a Java Application With dbx

18.  Debugging at the Machine-Instruction Level

19.  Using dbx With the Korn Shell

20.  Debugging Shared Libraries

A.  Modifying a Program State

B.  Event Management

C.  Macros

D.  Command Reference


Setting Filters on Breakpoints

In dbx, most of the event management commands also support an optional event filter modifier. The simplest filter instructs dbx to test for a condition after the program arrives at a breakpoint or trace handler, or after a data change breakpoint occurs.

If this filter condition evaluates to true (non 0), the event command applies and program execution stops at the breakpoint. If the condition evaluates to false (0), dbx continues program execution as if the event had never happened.

To set a breakpoint that includes a filter at a line or in a function, add an optional- if condition modifier statement to the end of a stop or trace command.

The condition can be any valid expression, including function calls, returning Boolean or integer in the language current at the time the command is entered.

With a location-based breakpoint like in or at, the scope for parsing the condition is that of the breakpoint location. Otherwise, the scope of the condition is the scope at the time of entry, not at the time of the event. You might have to use the backquote operator (see Backquote Operator) to specify the scope precisely.

These two filters are not the same:

stop in foo -if a>5
stop cond a>5

The former breaks at foo and tests the condition. The latter automatically single steps and tests for the condition.

Using the Return Value of a Function Call as a Filter

You can use a function call as a breakpoint filter. In this example, if the value in the string str is abcde, then execution stops in function foo():

(dbx) stop in foo -if !strcmp(“abcde”,str)

Setting Data Change Breakpoints on Local Variables

Filters can be convenient when you are placing a data change breakpoint on a local variable. In the following example, the current scope is in function foo(), while index, the variable of interest, is in function bar().

(dbx) stop access w &bar`index -in bar

bar`index ensures that the index variable in function bar() is picked up, instead of the index variable in function foo or a global variable named index.

-in bar implies the following:

The stack location corresponding to index might be reused by some other local variable of some other function. -in ensures that the breakpoint is triggered only when bar`index is accessed.

Using a Filter With a Conditional Event

New users sometimes confuse setting a conditional event command (a watch-type command) with using filters. Conceptually, “watching” creates a precondition that must be checked before each line of code executes (within the scope of the watch). But even a breakpoint command with a conditional trigger can also have a filter attached to it.

Consider this example:

(dbx) stop access w &speed -if speed==fast_enough

This command instructs dbx to monitor the variable, speed; if the variable speed is written to (the “watch” part), then the -if filter goes into effect. dbx checks whether the new value of speed is equal to fast_enough. If it is not, the program continues, “ignoring” the stop command.

In dbx syntax, the filter is represented in the form of an [-if condition] statement at the end of the command.

stop in function [-if condition]

If you set a breakpoint with a filter that contains function calls in a multithreaded program, dbx stops execution of all threads when it hits the breakpoint, and then evaluates the condition. If the condition is met and the function is called, dbx resumes all threads for the duration of the call.

For example, you might set the following breakpoint in a multithreaded application where many threads call lookup():

(dbx) stop in lookup -if strcmp(name, “troublesome”) == 0

dbx stops when thread t@1 calls lookup(), evaluates the condition, and calls strcmp() resuming all threads. If dbx hits the breakpoint in another thread during the function call, it issues a warning such as one of the following:

event infinite loop causes missed events in the following handlers:
Event reentrancy
first event BPT(VID 6m TID 6, PC echo+0x8)
second event BPT*VID 10, TID 10, PC echo+0x8)
the following handlers will miss events:

In such a case, if you can ascertain that the function called in the conditional expression will not grab a mutex, you can use the -resumeone event specification modifier to force dbx to resume only the first thread in which it hit the breakpoint. For example, you might set the following breakpoint:

(dbx) stop in lookup -resumeone -if strcmp(name, “troublesome”) == 0

The -resumeone modifier does not prevent problems in all cases. For example, it would not help if:

For detailed information on event modifiers, see Event Specification Modifiers.