Impacts of Running a Program Under dbx

You use dbx to observe a process, and the observation should not perturb the process. However, on occasion, you might drastically modify the state of the process. And sometimes plain observation can perturb execution and cause bug symptoms to come and go mysteriously.

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.soloaded into a program can cause the program to behave differently.

• Your dbx initialization scripts might 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 the contents of argv[], forcing local variables to be allocated differently. If they’re not initialized, they will get different random numbers. This problem can be detected using runtime checking.

• The program does not initialize memory allocated with malloc()() before use; a situation similar to the previous one. 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 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, 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 may 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.