转自www.codeguru.com
When you compile a debug build of your program with Visual Studio and run it in debugger, you can see that the memory allocated or deallocated has funny values, such as 0xCDCDCDCD or 0xDDDDDDDD. This is the result of the work Microsoft has put in to detect memory corruption and leaks in the Win32 platform. In this article, I will explain how memory allocation/deallocation is done via new/delete or malloc/free.
First, I will explain what all these values that you see, like CD, DD, and so forth, mean.
ValueNameDescription0xCDClean MemoryAllocated memory via malloc or new but never written by the application.0xDDDead MemoryMemory that has been released with delete or free. It is used to detect writing through dangling pointers.0xFDFence MemoryAlso known as "no mans land." This is used to wrap the allocated memory (like surrounding it with fences) and is used to detect indexing arrays out of bounds.0xAB(Allocated Block?)Memory allocated by LocalAlloc().0xBAADF00DBad FoodMemory allocated by LocalAlloc() with LMEM_FIXED, but not yet written to.0xCC When the code is compiled with the /GZ option, uninitialized variables are automatically assigned to this value (at byte level).
If you take a look at DBGHEAP.C, you can see how some of these values are defined:
static
本文地址：http://com.8s8s.com/it/it22521.htm