Debugging with GDB (February 2008)

Table Of Contents
148 Debugging with GDB
14.10.8.3 Stop when a specified block address is allocated or
deallocated
To stop a program whenever a block at a specified address is allocated or deallocated,
use the command:
set heap-check watch address
You can use this to debug situations such as multiple free() calls to the same block.
Limitation : This is not supported in batch mode debugging.
14.10.8.4 Scramble previous memory contents at malloc/free
calls
WDB enables you to potentially expose latent memory access defects with the com-
mand:
In Interactive debugging mode: set heap-check scramble [on | off]
In batch mode debugging: scramble_blocks [on | off].
When this setting is turned on, any time a memory block is allocated or deallocated,
WDB scrambles the space and overwrites it with a specific pattern.
This change to the memory contents increases the chance that erroneous behaviors will
cause the program to fail. Examples of such behavior include attempting to access
space that is freed or depending on initial values of malloc() blocks.
You can now look at the stack trace to understand where and how the problem occurred.
Note: Turning on scrambling slows down the program slightly, because at
every malloc() and free() call, the space involved must be overwritten.
14.10.8.5 Detect dangling pointers and dangling blocks
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.
Note:
Software literature names this concept as premature free or Reading/writing freed mem-
ory 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.
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.
Note: