Various strange padding values in the heap memory

Various strange padding values in the "Go" heap memory various strange padding values in the heap memory

2012-6-27 Finishing

Cswuyg

A few days ago encountered a wonderful code, with 0xFEEEFEEE to determine whether it is a dangling pointer, this must oppose, too risky.

What else is the padding value? It is not so simple to find a thorough analysis, but finally to get some information on the network to this place as a record.

First, release, with ollydbg view

1, the application of 50 bytes of space. You can see that it is initialized to 0xbaadf00d.

2. After releasing the requested memory, the memory is initialized to 0xFEEEFEEE after release.

Second, debug under Use VS2005 view

1, the application of 50 bytes of space. You can see that it is initialized to 0XCDCDCDCD

2. After releasing the requested memory, initialize to 0xFEEEFEEE

Iii. Summary

According to an article on the Web: "The CRT will typically call the HeapFree () function to return this memory block to the Win32 heap, and the Win32 heap will populate this memory block with 0xFEEEFEEE." In other words, debug, release will appear 0xFEEEFEEE, because they will call the HeapFree () function.

The memory returned by HeapAlloc () is always initialized to 0xbaadf00d by 14-byte alignment, which means that the memory under release is directly the result of the HeapAlloc operation and no additional operations are made outside the world. And debug, it will be initialized again, into 0xCDCDCDCD.

In addition, it is important to note that this information is only used to understand, do not use them in the program, this is compiler-related things.

I tried to verify that the information I found on the web was not so simple, even in the release mode where the compiler was doing the least amount of memory additional processing, the request for memory space was much more complicated than the previously tested GCC, requesting 8 bytes of space, But see the memory has 40 byte value has changed, and finally found that it seems that 8byte of space occupies 32byte of memory, there is not a lot of time spent here to guess the additional space and its use of padding values, so it is, these are relatively biased knowledge. The allocation details of the heap space, in contrast to GCC, are much simpler, and you can test these differences with Code::block.

Attach a very detailed explanation on the Internet:

* 0xabababab:used by Microsoft's HeapAlloc () to mark "No Man's Land" guard bytes after allocated heap memory

* 0xabadcafe:a startup to the "value to initialize all" memory to catch errant pointers

* 0xbaadf00d:used by Microsoft's LocalAlloc (lmem_fixed) to mark uninitialised allocated heap memory

* 0xbadcab1e:error Code returned to the Microsoft EVC debugger when connection are severed to the debugger

* 0xbeefcace:used by Microsoft. NET as a magic number in resource files

* 0xcccccccc:used by Microsoft ' s C + + debugging Runtime library to mark Uninitialised stack memory

* 0xcdcdcdcd:used by Microsoft ' s C + + debugging Runtime library to mark Uninitialised heap memory

* 0xdeaddead:a Microsoft Windows STOP Error code used when the user manually initiates the crash

* 0xfdfdfdfd:used by Microsoft ' s C + + debugging heap to mark "No Man's Land" guard bytes before and after allocated heap Memory

* 0xfeeefeee:used by Microsoft's HeapFree () to mark freed heap memory