This appendix focuses on dbx usage and commands that change your program or change the behavior of your program as compared to running it without dbx. It is important to understand which commands might make modifications to your program.
The chapter is divided into the following sections:
Your application might behave differently when run under dbx. Although dbx strives to minimize its impact on the program being debugged, you should be aware of the following:
You might have forgotten to take out a -C or disable RTC. Just having the RTC support library librtc.so loaded into a program can cause the program to behave differently.
Your dbx initialization scripts may have some environment variables set that you've forgotten about. The stack base starts at a different address when running under dbx. This is also different based on your environment and contents of argv[], forcing local variables to be allocated a bit differently. If they're not initialized, they will get different random numbers. This problem can be detected via runtime checking.
The program does not initialize malloc()'ed memory before use; a situation similar to the previous one. This problem can be detected via runtime checking.
dbx has to catch LWP creation and dlopen events, which might affect timing-sensitive multithreaded applications.
dbx does context switching on signals, so if your application makes heavy use of signals, things might work differently.
Your program might be expecting that mmap() always returns the same base address for mapped segments. Running under dbx perturbs the address space sufficiently to make it unlikely that mmap() returns the same address as when the program is run without dbx. To determine if this is a problem in your program, look at all uses of mmap() and ensure that the address returned is actually used by the program, rather than a hard-coded address.
If the program is multithreaded, it may contain data races or be otherwise dependent upon thread scheduling. Running under dbx perturbs thread scheduling and may cause the program to execute threads in a different order than normal. To detect such conditions, use lock_lint.
Otherwise, see if running with adb or truss causes the same problems.
To minimize perturbations imposed by dbx, try attaching to the application while it is running in its natural environment.
The dbx assign command assigns a value of the exp to var. Using it in dbx permanently alters the value of var.
assign var = exp
The dbx pop command pops a frame or frames from the stack:
Pop current frame | pop |
Pop num frames | pop num |
Pop frames until specified frame number |
pop -f num |
Any calls popped are re-executed upon resumption, which may result in undesirable program changes. pop also calls destructors for objects local to the popped functions.
When you use the call command in dbx you call a procedure, and the procedure performs as specified:
call proc([params])
The procedure could modify something in your program. dbx is actually making the call as if you had written it into your program source.
To print the value of the expression(s):
print exp, ...
If an expression has a function call, the same considerations apply as with the call command. With C++, you should also be careful of unexpected side effects caused by overloaded operators.
The when command has a general syntax as follows:
when event-specification [modifier] {cmd ... ;}
When the event occurs, the cmds are executed.
When you get to a line or to a procedure, a command is performed. Depending upon which command is issued, this could alter your program state.
You can use fix to make on-the-fly changes to your program:
fix
It is a very useful tool, but remember that fix recompiles modified source files and dynamically links the modified functions into the application.
Make sure to check the restrictions for fix and continue. See Chapter 11, Fixing and Continuing."
This dbx command alters the order in which the program runs. Execution is continued at line line. id is required if the program is multithreaded.
cont at line id
This could change the outcome of the program.