Using Guard Blocks
When a program allocates a memory block, it is responsible for not writing data outside the block. For example, if you allocate 16 bytes, you do not want to write 32 bytes of information into it because this data would corrupt the information contained in the next block.
MemoryScape can help you detect problems related to writing data either before or after a block by surrounding blocks with a small amount of additional memory. It will also write a pattern into this memory. These additional memory blocks are called guard blocks. If your program writes data into these blocks, MemoryScape can tell that a problem occurred, as follows:
When you are displaying a Heap Status report, you can ask for a Corrupted Guard Blocks report. The Heap Status report also shows the guard regions and corrupted blocks.
When your program deallocates memory, MemoryScape can check the deallocated block’s guards. If they’ve been altered—that is, if your program has written data into them—MemoryScape can stop execution and alert you to the problem.
For example, suppose your program allocates 16 bytes and you write 64 bytes of data. While the first 16 bytes are correctly written, the remaining 48 aren’t. This write request will also overwrite the guard blocks for the current block and the block that follows, as well as some of the next block’s data. That is, you will have inadvertently changed some data—data that when accessed will be incorrect.
Asking for notification when the block is deallocated lets you know that a problem has occurred. Because you now know which block was corrupted, you can begin to locate the cause of the problem. In many cases, you will rerun your program, focusing on those blocks.