Debugging Your Program With dbx
You are likely to be debugging your program for one of the following reasons:
- To determine where and why it is crashing. Strategies for locating the cause of a crash include:
- Running the program in dbx. dbx reports the location of the crash when it occurs.
- Examining the core file and looking at a stack trace (see Examining a Core File and Looking at the Call Stack).
- To determine why your program is giving incorrect results. Strategies include:
- Setting breakpoints to stop execution so that you can check your program's state and look at the values of variables (see Setting Breakpoints and Examining Variables).
- Stepping through your code one source line at a time to monitor how the program state changes (see Stepping Through Your Program).
- To find a memory leak or memory management problem. Runtime checking lets you detect runtime errors such as memory access errors and memory leak errors and lets you monitor memory usage (see Finding Memory Access Problems and Memory Leaks).
Examining a Core File
To determine where your program is crashing, you may want to examine the core file, the memory image of your program when it crashed. You can use the where command (see where Command) to determine where the program was executing when it dumped core.
|
Note - dbx cannot tell you the state of a Java application from a core file as it can with native code. |
In the following example, the program has crashed with a segmentation fault and dumped core. The user starts dbx and loads the core file. Then he uses the wherecommand to display a stack trace, which shows that the crash occurred at line 9 of the file foo.c.
For more information on debugging core files, see Debugging a Core File. For more information on using the call stack, see Looking at the Call Stack.
|
Note - If your program is dynamically linked with any shared libraries, it is best to debug the core file in the same operating environment in which it was created. For information on debugging a core file that was created in a different operating environment, see Debugging a Mismatched Core File. |
Setting Breakpoints
A breakpoint is a location in your program where you want the program to stop executing temporarily and give control to dbx. Set breakpoints in areas of your program where you suspect bugs. If your program crashes, determine where the crash occurs and set a breakpoint just before this part of your code.
When your program stops at a breakpoint, you can then examine the state of program and the values of variables. dbx allows you to set many types of breakpoints (seeChapter 6).
The simplest type of breakpoint is a stop breakpoint. You can set a stop breakpoint to stop in a function or procedure. For example, to stop when the main function is called:
For more information on the stop in command, see Setting a stop Breakpoint in a Function and stop Command.
Or you can set a stop breakpoint to stop at a particular line of source code. For example, to stop at line 13 in the source file t.c:
For more information on the stop at command, see Setting a stop Breakpoint at a Line of Source Code and stop Command.
You can determine the line at which you wish to stop by using the file command to set the current file and the list command to list the function in which you wish to stop. Then use the stop at command to set the breakpoint on the source line:
(dbx) file t.c (dbx) list main 10 main(int argc, char *argv[]) 11 { 12 char *msg = "hello world\n"; 13 printit(msg); 14 } (dbx) stop at 13 (4) stop at "t.c":13 |
To continue execution of your program after it has stopped at a breakpoint, use the cont command (see Continuing Execution of a Program and cont Command).
To get a list of all current breakpoints use the status command:
Now if you run your program, it stops at the first breakpoint:
Stepping Through Your Program
After you have stopped at a breakpoint, you may want to step through your program one source line at a time while you compare its actual state with the expected state. You can use the step and next commands to do so. Both commands execute one source line of your program, stopping when that line has completed execution. The commands handle source lines that contain function calls differently: the step command steps into the function, while the next command steps over the function.
The step up command continues execution until the current function returns control to the function that called it.
The step to command attempts to step into a specified function in the current source line, or if no function is specified, into the last function called as determined by the assembly code for the current source line.
Some functions, notably library functions such as printf, may not have been compiled with the -g option, so dbx cannot step into them. In such cases, step and nextperform similarly.
The following example shows the use of the step and next commands as well as the breakpoint set in Setting Breakpoints.
For more information on stepping through your program, see Stepping Through a Program. For more information on the step and next commands, see step Command andnext Command.
Looking at the Call Stack
The call stack represents all currently active routines--those that have been called but have not yet returned to their respective caller. In the stack, the functions and their arguments are listed in the order in which they were called. A stack trace shows where in the program flow execution stopped and how execution reached this point. It provides the most concise description of your program's state.
To display a stack trace, use the where command:
For functions that were compiled with the -g option, the arguments names and their types are known so accurate values are displayed. For functions without debugging information hexadecimal numbers are displayed for the arguments. These numbers are not necessarily meaningful. For example, in the stack trace above, frame 1 shows the contents of the SPARC input registers $i0 through $i5; only the contents of registers $i0 through $i1 are meaningful since only two arguments were passed to printf in the example shown in Stepping Through Your Program.
You can stop in a function that was not compiled with the -g option. When you stop in such a function dbx searches down the stack for the first frame whose function is compiled with the -g option--in this case printit()--and sets the current scope (see Program Scope) to it. This is denoted by the arrow symbol (=>).
For more information on the call stack, see Chapter 7.
Examining Variables
While a stack trace may contain enough information to fully represent the state of your program, you may need to see the values of more variables. The print command evaluates an expression and prints the value according to the type of the expression. The following example shows several simple C expressions:
(dbx) print msg msg = 0x20a84 "Hello world" (dbx) print msg[0] msg[0] = 'h' (dbx) print *msg *msg = 'h' (dbx) print &msg &msg = 0xefffe8b4 |
You can track when the values of variables and expressions change using data change breakpoints (see Setting Data Change Breakpoints). For example, to stop execution when the value of the variable count changes, type:
Finding Memory Access Problems and Memory Leaks
Runtime checking consists of two parts: memory access checking, and memory use and leak checking. Access checking checks for improper use of memory by the debugged application. Memory use and leak checking involves keeping track of all the outstanding heap space and then on demand or at termination of the program, scanning the available data spaces and identifying the space that has no references.
|
Note - Runtime checking is available only on Solaris platforms. |
Memory access checking, and memory use and leak checking, are enabled with the check command. To turn on memory access checking only, type:
To turn on memory use and memory leak checking, type:
After turning on the types of runtime checking you want, run your program. The program runs normally, but slowly because each memory access is checked for validity just before it occurs. If dbx detects invalid access, it displays the type and location of the error. You can then use dbx commands such as where to get the current stack trace orprint to examine variables.
|
Note - You cannot use runtime checking on an application that is a mixture of Java code and C JNI code or C++ JNI code. |
For detailed information on using runtime checking, see Chapter 9.
A dbx session runs from the time you start dbx until you quit dbx; you can debug any number of programs in succession during a dbx session.
To quit a dbx session, type quit at the dbx prompt.
When you start dbx and attach it to a running process using the process_id option, the process survives and continues when you quit the debugging session. dbx performs an implicit detach before quitting the session.
For more information about quitting dbx, see Quitting Debugging.
dbx includes a help file that you can access with the help command:
http://docs.oracle.com/cd/E19422-01/819-3683/getting_started.html#pgfId-26812 dbx http://docs.oracle.com/cd/E19422-01/819-3683/getting_started.html#pgfId-26812 dbx
Debugging Your Program With dbx
PDF download ： http://docs.oracle.com/cd/E19422-01/819-3683-10/819-3683-10.pdf