In this section:
This error is generated when a dynamic memory block has become corrupt. Usually, the corruption is the result of a WRITE_OVERFLOW or WRITE_BAD_INDEX. This error is most often detected as the memory is being returned to the system.
Insure++ uses guard zones around dynamically allocated memory to help detect heap corruption that is otherwise difficult or impossible to discover. This feature can be turned on or off in the .psrc file. Dynamic memory heap is corrupt
Code Description Enabled Reported Platform HEAP_CORRUPT Runtime Windows/Unix
Dynamic memory heap is corrupt
The following code will generate a WRITE_BAD_INDEX and a subsequent HEAP_CORRUPT:
Diagnosis at Runtime
- Line 2: Source line at which the problem was detected.
- Line 3: Description of the problem.
- Line 4: Schematic showing the relative layout in memory of the block and the corrupted guard zone.
- Line 7: Range of corrupted memory showing the guard zone, the expected memory pattern, and the pattern that was found instead.
- Line 11: The memory block that is most likely the one that has been corrupted and the stack trace of its allocation.
- Line 15: The stack trace where the memory was freed, (may or may not be present).
- Line 18: The stack trace showing the call sequence to the error.
- Line 21: Informational message indicating that a serious error has occurred, which may cause the program to crash.
Look for previous WRITE_OVERFLOW or WRITE_BAD_INDEX errors—they might lead you to this particular error. If there aren't any, that means that the heap became corrupt in some uninstrumented code. Carefully examine all functions in all of the stack back traces to try to find the source of the problem.
Use a debugger to set a break point at the allocation location, then a watchpoint on the guardzone area which became corrupt. For example, in the sample code above, a watchpoint could be set on the memory at address
0x804b022. When the breakpoint "fires", you've found the bug.
The following example uses Linux's gcc and gdb:
To figure out what happened, look at GDB:
The memory is about to be allocated. Be sure that it's getting allocated correctly:
If the guard zone has the right pattern in it (as shown above), set a watchpoint on this memory location:
If you examine the source code immediately before the location where the watchpoint stopped, you can see the following:
The code shows that the memory became corrupt on line 7. To examine the backtrace to see how you got there:
Careful examination of line 13 of the file heapcrpt shows the problem: Wrong string offset sent down to function