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


Efficiency Considerations

Various events have different degrees of overhead in respect to the execution time of the program being debugged. Some events, like the simplest breakpoints, have practically no overhead. Events based on a single breakpoint have minimal overhead.

Multiple breakpoints such as inclass, that might result in hundreds of breakpoints, have an overhead only during creation time. dbx uses permanent breakpoints; the breakpoints are retained in the process at all times and are not taken out on every stoppage and put in on every cont command.

Note - In the case of the step command and next command, by default all breakpoints are taken out before the process is resumed and reinserted once the step completes. If you are using many breakpoints or multiple breakpoints on prolific classes, the speed of the step command and next command slows down considerably. Use the dbx step_events environment variable to control whether breakpoints are taken out and reinserted after each step command or next command.

The slowest events are those that utilize automatic single stepping. This might be explicit and obvious as in the trace step command, which single steps through every source line. Other events, like the stop change expression or trace cond variable not only single step automatically but also have to evaluate an expression or a variable at each step.

These events are very slow, but you can often overcome the slowness by bounding the event with a function using the -in modifier. For example:

trace next -in mumble
stop change clobbered_variable -in lookup

Do not use trace -in main because the trace is effective in the functions called by main as well. Do use it in the cases where you suspect that the lookup() function is clobbering your variable.