Debugging Dynamic Memory Usage Errors Using HP WDB (5900-1474; WDB 6.2; January 2011)

(gdb) run
Starting program: infobounds
Breakpoint 1, main ()
at .infobounds.c:25
25 printf("Hello\n");
(gdb) info corruption
Analyzing heap ...
Following blocks appear to be corrupted
No. Total bytes Blocks Address Function
0 10 1 0x400124e0 sm_malloc()
1 10 1 0x40012500 sm_malloc()
2 10 1 0x40012520 sm_malloc()
(gdb) info corruption 2
10 bytes at 0x40012520 (33.33% of all bytes allocated)
#0 sm_malloc() at infobounds.c:12
#1 main() at infobounds.c:21
#2 main_opd_entry() from /usr/lib/hpux32/dld.so
(gdb)
Sample output that displays the in-block corruption of freed blocks:
info corruption
Analyzing heap ...
Following blocks appear to be corrupted
No. Total bytes Blocks Corruption Address Function
0 10 1 End of block 0x8000000100966548 sm_malloc()
1 10 1 Inside block 0x8000000100966578 sm_malloc()
2 10 1 Beginning 0x80000001009665a8 sm_malloc()
NOTE: This display is possible only if the set heap-check retain-freed-blocks
command is set to on.
Detecting dangling pointer and dangling block
A pointer is a Dangling pointer if the block of memory it points to, has been freed by
the application. The block is called Dangling Block.
The same freed block could be subsequently allocated to the application in response to
another memory allocation request. In this scenario, if the application incorrectly tries to
write into the freed memory block using the dangling pointer, it could result in incorrect
or an undefined program behavior, as the new owner or function owning the same
allocated block would find different values in the heap block.
The info dangling command displays a list of all the dangling pointers and dangling
blocks that are potential sources of memory corruption.
Memory-Debugging Features of WDB 53