Debugging Dynamic Memory Usage Errors Using HP WDB v6.3 (5900-2181, August 2012)

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.
• To get the latest memory corruption details for a particular corrupted block with number <num>,
you must first enter the info corruption command followed by info corruption
<num>.
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.
NOTE: Software literature names this concept as premature free or Reading/writing freed memory
using a pointer.
WDB tracks the dangling pointers and dangling blocks using a modified version of Garbage
collection. The enabler for doing this is by retaining all the freed blocks internally within RTC without
actually freeing it as long as possible. It displays all the potential pointers to the freed dangling
blocks, in the application data space. WDB turns on these checks, only when you specify set
heap-check retain-freed-blocks to on.
The pointers are potential because the pointers need not be actual pointers and could be a datum
value and hence there are chances of false positives in the Dangling report.
Memory-Debugging Features of WDB 43