Debugging Memory Problems with MemoryScape : Chapter 1 Locating Memory Problems : Your Program’s Data : The Heap : Finding Heap Deallocation Problems
Finding Heap Deallocation Problems
MemoryScape can let you know when your program encounters a problem in deallocating memory. Some of the problems it can identify are:
*free() not allocated: An application calls the free() function by using an address that is not in a block allocated in the heap.
*realloc() not allocated: An application calls the realloc() function by using an address that is not in a block allocated in the heap.
*Address not at start of block: A free() or realloc() function receives a heap address that is not at the start of a previously allocated block.
If a library routine uses the program’s memory manager (that is, it is using the heap API) and a problem occurs, MemoryScape still locates the problem. For example, the strdup() string library function calls the malloc() function to create memory for a duplicated string. Since the strdup() function is calling the malloc() function, MemoryScape can track this memory.
MemoryScape can stop execution just before your program misuses a heap API operation. This lets you see what the problem is before it actually occurs. (For a reminder, see Behind the Scenes”.)
* 
When Memory Scape is used with TotalView, execution stops before your program’s heap manager deallocates memory, you can use the Thread > Set PC command to set the PC to a line after the free() request. This means that you can continue debugging past a problem that might cause your program to crash. In this case, the problem is solved while in the debugger. You still need to fix the problem.