This appendix focuses on dbx usage and commands that change your program or change the behavior of your program when you run it under dbx, as compared to running it without dbx. Understanding which commands might make modifications to your program is important.
The chapter contains the following sections:
You use dbx to observe a process, and the observation should not affect the process. However, on occasion, you might drastically modify the state of the process. Sometimes plain observation can affect execution and cause intermittent bug symptoms.
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. Having the RTC support library librtc.so loaded into a program can cause the program to behave differently.
Your dbx initialization scripts might have some environment variables set that you have forgotten. The stack base starts at a different address when running under dbx. The address might also different based on your environment and the contents of argv[], forcing local variables to be allocated differently. If the variables are not initialized, they will produce different random numbers. This problem can be detected using runtime checking.
The program does not initialize memory allocated with malloc() before use. This problem can be detected using 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 affects the address space sufficiently that mmap() is unlikely to return the same address as when the program is run without dbx. To determine if this is a problem, look at all uses of mmap() and ensure that the address returned is used by the program, rather than a hard-coded address.
If the program is multithreaded, it might contain data races or be otherwise dependent upon thread scheduling. Running under dbx perturbs thread scheduling and might cause the program to execute threads in a different order than normal. To detect such conditions, use lock_lint.
Otherwise, determine whether 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 commands described in this section might make modifications to your program.
The assign command assigns the value of expression to variable. Using it in dbx permanently alters the value of variable.
assign variable = expression
The pop command pops a frame or frames from the stack:
Pop current frame.
Pop number frames.
Pop frames until specified frame number.
Any calls popped are re-executed upon resumption, which might result in unwanted program changes. pop also calls destructors for objects local to the popped functions.
For more information, see pop Command.
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 your program. dbx makes the call as if you had written it into your program source.
For more information, see call Command.
To print the value of the expressions, type:
print expression, ...
If an expression has a function call, printing the expression causes the call command to execute. Therefore, the same considerations apply as with the call Command. With C++, you should also be careful of unexpected side effects caused by overloaded operators.
For more information, see print Command.
The general syntax of the when command is as follows:
when event-specification [modifier] {command; ... }
When the event occurs, the commands are executed. Depending upon which command is issued, this action could alter your program state.
For more information, see when Command.
You can use the fix command to make immediate changes to your program.
Although it is a very useful tool, the fix command recompiles modified source files and dynamically links the modified functions into the application.
Make sure to check the restrictions for fix and continue. See Memory Leak (mel) Error.
For more information, see fix Command.
The cont at command alters the order in which the program runs. Execution is continued at line line. The ID is required if the program is multithreaded.
cont at line [ ID ]
This command could change the outcome of the program.