4. Viewing and Navigating To Code
5. Controlling Program Execution
6. Setting Breakpoints and Traces
8. Evaluating and Displaying Data
Turning On Memory Use and Memory Leak Checking
Turning On Memory Access Checking
Turning On All Runtime Checking
Understanding the Memory Access Error Report
Understanding the Memory Leak Report
Limiting the Number of Errors Reported
Using Suppression to Manage Errors
Using Runtime Checking on a Child Process
Using Runtime Checking on an Attached Process
Using Fix and Continue With Runtime Checking
Runtime Checking Application Programming Interface
Using Runtime Checking in Batch Mode
Enabling Batch Mode Directly From dbx
Works Better With More Symbols and Debug Information
SIGSEGV and SIGALTSTACK Signals Are Restricted on x86 Platforms
Read From Array Out-of-Bounds (rob) Error
Read From Unallocated Memory (rua) Error
Read From Uninitialized Memory (rui) Error
Write to Array Out-of-Bounds Memory (wob) Error
Write to Read-Only Memory (wro) Error
Write to Unallocated Memory (wua) Error
Address in Register (air) Error
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
Because runtime checking is an integral debugging feature, you can perform all debugging operations while using runtime checking except collecting performance data using the Collector.
Runtime checking:
Detects memory access errors
Detects memory leaks
Collects data on memory use
Works with all languages
Works with multithreaded code
Requires no recompiling, relinking, or makefile changes
Compiling with the -g flag provides source line number correlation in the runtime checking error messages. Runtime checking can also check programs compiled with the optimization -O flag. There are some special considerations with programs not compiled with the -g option.
You can use runtime checking by using the check command.
One way to avoid seeing a large number of errors at once is to use runtime checking earlier in the development cycle, as you are developing the individual modules that make up your program. Write a unit test to drive each module and use runtime checking incrementally to check one module at a time. That way, you deal with a smaller number of errors at a time. When you integrate all of the modules into the full program, you are likely to encounter few new errors. When you reduce the number of errors to zero, you need to run runtime checking again only when you make changes to a module.
To use runtime checking, you must fulfill the following requirements:
Dynamic linking with libc.
Use of the standard libc malloc, free, and realloc functions or allocators based on those functions. Runtime checking provides an application programming interface (API) to handle other allocators. See Runtime Checking Application Programming Interface.
Programs that are not fully stripped; programs stripped with strip -x are acceptable.
For information on the limitations of runtime checking, see Runtime Checking Limitations.