Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Studio 12.3: Debugging a Program With dbx Oracle Solaris Studio 12.3 Information Library |
4. Viewing and Navigating To Code
5. Controlling Program Execution
6. Setting Breakpoints and Traces
8. Evaluating and Displaying Data
11. Debugging Multithreaded Applications
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
Breakpoint Event Specifications
inmember function inmethod function
inclass classname [-recurse | -norecurse]
inobject object-expression [-recurse | -norecurse]
Data Change Event Specifications
access mode address-expression [, byte-size-expression]
dlopen [ lib-path ] dlclose [ lib-path ]
Execution Progress Event Specifications
Variables Valid for when Command
The following are some examples of setting event handlers.
To set a data change breakpoint on array[99], type:
(dbx) stop access w &array[99] (2) stop access w &array[99], 4 (dbx) run Running: watch.x2 watchpoint array[99] (0x2ca88[4]) at line 22 in file "watch.c" 22 array[i] = i;
To implement a simple trace, type:
(dbx) when step { echo at line $lineno; }
To enable a handler while within a function, type:
<dbx> trace step -in foo
This is equivalent to:
# create handler in disabled state when step -disable { echo Stepped to $line; } t=$newhandlerid # remember handler id when in foo { # when entered foo enable the trace handler -enable "$t" # arrange so that upon returning from foo, # the trace is disabled. when returns { handler -disable "$t"; }; }
To see how many lines have been executed in a small program, type:
(dbx) stop step -count infinity # step and stop when count=inf (2) stop step -count 0/infinity (dbx) run ... (dbx) status (2) stop step -count 133/infinity
The program never stops, the program terminates. The number of lines executed is 133. This process is very slow. It is most useful with breakpoints on functions that are called many times.
To count how many instructions a line of code executes, type:
(dbx) ... # get to the line in question (dbx) stop step -instr -count infinity (dbx) step ... (dbx) status (3) stop step -count 48/infinity # 48 instructions were executed
If the line you are stepping over makes a function call, the lines in the function are counted as well. You can use the next event instead of step to count instructions, excluding called functions.
Enable a breakpoint only after another event has occurred. For example, if your program begins to execute incorrectly in function hash, but only after the 1300’th symbol lookup, you would type:
(dbx) when in lookup -count 1300 { stop in hash hash_bpt=$newhandlerid when proc_gone -temp { delete $hash_bpt; } }
Note - $newhandlerid is referring to the just executed stop incommand.
If your application processes files that need to be reset during a replay, you can write a handler to do that each time you run the program:
(dbx) when sync { sh regen ./database; } (dbx) run < ./database... # during which database gets clobbered (dbx) save ... # implies a RUN, which implies the SYNC event which (dbx) restore # causes regen to run
To see quickly where the program is while it is running, type:
(dbx) ignore sigint (dbx) when sig sigint { where; cancel; }
Then type ^C to see a stack trace of the program without stopping it.
This is basically what the collector hand sample mode does (and more). Use SIGQUIT (^\) to interrupt the program because ^C is now used up.
To catch only specific floating point exceptions, for example, IEEE underflow, type:
(dbx) ignore FPE # turn off default handler (dbx) help signals | grep FPE # can’t remember the subcode name ... (dbx) stop sig fpe FPE_FLTUND ...