4. Viewing and Navigating To Code
5. Controlling Program Execution
6. Setting Breakpoints and Traces
8. Evaluating and Displaying Data
Capabilities of Runtime Checking
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
Memory use checking lets you see all the heap memory in use. You can use this information to get a sense of where memory is allocated in your program or which program sections are using the most dynamic memory. This information can also be useful in reducing the dynamic memory consumption of your program and might help in performance tuning
Memory use checking is useful during performance tuning or to control virtual memory use. When the program exits, a memory use report can be generated. Memory usage information can also be obtained at any time during program execution with the showmemuse command, which causes memory usage to be displayed. For information, see showmemuse Command.
Turning on memory use checking also turns on leak checking. In addition to a leak report at the program exit, you also get a blocks in use (biu) report. By default, a nonverbose blocks in use report is generated at program exit. The level of detail in the memory use report is controlled by the dbx environment variable rtc_biu_at_exit (see Setting dbx Environment Variables).
The following is a typical nonverbose memory use report.
Blocks in use report (blocks in use: 5 total size: 40 bytes) Total % of Num of Avg Allocation call stack Size All Blocks Size ========== ==== ====== ====== ===================================== 16 40% 2 8 nonleak < nonleak 8 20% 1 8 nonleak < main 8 20% 1 8 cyclic_leaks < main 8 20% 1 8 cyclic_leaks < main
Blocks in use report (blocks in use: 5 total size: 40 bytes) Block in use (biu): Found 2 blocks totaling 16 bytes (40.00% of total; avg block size 8) At time of each allocation, the call stack was: [1] nonleak() at line 182 in "memuse.c" [2] nonleak() at line 185 in "memuse.c" Block in use (biu): Found block of size 8 bytes at address 0x21898 (20.00% of total) At time of allocation, the call stack was: [1] nonleak() at line 182 in "memuse.c" [2] main() at line 74 in "memuse.c" Block in use (biu): Found block of size 8 bytes at address 0x21958 (20.00% of total) At time of allocation, the call stack was: [1] cyclic_leaks() at line 154 in "memuse.c" [2] main() at line 118 in "memuse.c" Block in use (biu): Found block of size 8 bytes at address 0x21978 (20.00% of total) At time of allocation, the call stack was: [1] cyclic_leaks() at line 155 in "memuse.c" [2] main() at line 118 in "memuse.c" The following is the corresponding verbose memory use report:
You can ask for a memory use report any time with the showmemuse command.