Using Guard Blocks and Red Zones
Guard blocks and Red Zones complement each other in several ways and can be used together to find your memory corruption problem. While Red Zones have a high memory consumption overhead, they provide immediate notification when an illegal read or write occurs. Guard blocks add minimal overhead, but detect only illegal writes, and report corruptions only when the block is deallocated or when you generate a report. Finding a memory problem with MemoryScape may require a couple of passes to narrow down your problem.
Start by enabling guard blocks prior to running your program. You can run a Corrupt Memory report at any time to see whether you have any corrupted blocks. The report shows the blocks that are corrupt and where they were initially allocated. In your next run, turn off guard blocks and turn Red Zones on. If memory is tight, enable Red Zones only where needed, either manually or by using size ranges. MemoryScape should detect when a block is overwritten and stop execution.
A caveat here: the layout of memory is controlled by the heap manager and the operating system. Depending on the size of your allocated block and its alignment on the page of memory, there may be a gap between the block and the Red Zone. The overrun or underrun must be large enough to span the gap and reach the Red Zone, or MemoryScape will not generate an event. This is a potential issue only if you are using memalign or posix_memalign. For malloc and calloc, the gap will probably be one less than the size of the alignment, three or seven bytes. In any case, the block will still show up as having a corrupted guard block, because guard blocks are placed immediately before and after your allocated block without any gap.
Block Painting
Your program should initialize memory before it is used, and it should never use memory that is deallocated. MemoryScape can help you identify these kinds of problems by writing a bit pattern into memory as it is allocated or deallocated. You can either specify a pattern or use the default, as follows:
The default allocation pattern is 0xa110ca7f, which was chosen because it resembles the word “allocate”.
The default deallocation pattern is 0xdea110cf, which was chosen because it resembles the word “deallocate”. In most cases, you want MemoryScape to paint memory blocks when your program allocates them.
If your program displays this value, you’ll be able to tell what the problem is. In some cases, using these values will cause your program to crash. Because MemoryScape traps this action, you can investigate the cause of the problem.
You can turn painting on and off without restarting your program. If, for example, you change the deallocation pattern, you’ll have a better idea when your program deallocated the block. That is, because MemoryScape is using a different pattern after you change it, you will know if your program allocated or deallocated the memory block before or after you made the change.
If you are painting deallocated memory, you could be transforming a working program into one that no longer works. This is good, as MemoryScape will be telling you about a problem.