什么时候和为什么会操作系统初始化内存0XCD，0xDD等上的malloc /自由/新/删除吗？ [英] When and why will an OS initialise memory to 0xCD, 0xDD, etc. on malloc/free/new/delete?
问题描述
我知道，操作系统有时会初始化内存具有一定的图案，如0XCD和0xDD。我想知道的是，当和为什么发生这种情况。
I know that the OS will sometimes initialise memory with certain patterns such as 0xCD and 0xDD. What I want to know is when and why this happens.
当
这是特定于所使用的编译器？
Is this specific to the compiler used?
以同样的方式做的malloc /新和自由/删除工作，对于这一点？
Do malloc/new and free/delete work in the same way with regard to this?
它是特定于平台的？
它会发生在其他操作系统，如Linux或VxWorks的？
Will it occur on other operating systems, such as Linux or VxWorks?
为什么
我的理解是这仅发生在Win32的调试配置，它是用来检测内存超支和帮助编译器捕捉异常。
My understanding is this only occurs in Win32 debug configuration, and it is used to detect memory overruns and to help the compiler catch exceptions.
您可以给任何实际的例子来初始化这是怎么有用吗？
Can you give any practical examples as to how this initialisation is useful?
我记得读的东西（也许在code完成2），这是很好的初始化内存已知模式分配它的时候，和某些模式将触发在Win32中的中断，这将导致异常在调试器中显示。
I remember reading something (maybe in Code Complete 2) that it is good to initialise memory to a known pattern when allocating it, and certain patterns will trigger interrupts in Win32 which will result in exceptions showing in the debugger.
如何便携式是什么？
推荐答案
什么编译调试模式（支持可能由编译器版本而异），当微软的编译器使用的无主/未初始化的内存各种比特的快速摘要：
A quick summary of what Microsoft's compilers use for various bits of unowned/uninitialized memory when compiled for debug mode (support may vary by compiler version):
Value Name Description
------ -------- -------------------------
0xCD Clean Memory Allocated memory via malloc or new but never
written by the application.
0xDD Dead Memory Memory that has been released with delete or free.
Used to detect writing through dangling pointers.
0xED or Aligned Fence 'No man's land' for aligned allocations. Using a
0xBD different value here than 0xFD allows the runtime
to detect not only writing outside the allocation,
but to also detect mixing alignment-specific
allocation/deallocation routines with the regular
ones.
0xFD Fence Memory Also known as "no mans land." This is used to wrap
the allocated memory (surrounding it with a fence)
and is used to detect indexing arrays out of
bounds or other accesses (especially writes) past
the end (or start) of an allocated block.
0xFD or Buffer slack Used to fill slack space in some memory buffers
0xFE (unused parts of `std::string` or the user buffer
passed to `fread()`). 0xFD is used in VS 2005 (maybe
some prior versions, too), 0xFE is used in VS 2008
and later.
0xCC When the code is compiled with the /GZ option,
uninitialized variables are automatically assigned
to this value (at byte level).
// the following magic values are done by the OS, not the C runtime:
0xAB (Allocated Block?) Memory allocated by LocalAlloc().
0xBAADF00D Bad Food Memory allocated by LocalAlloc() with LMEM_FIXED,but
not yet written to.
0xFEEEFEEE OS fill heap memory, which was marked for usage,
but wasn't allocated by HeapAlloc() or LocalAlloc().
Or that memory just has been freed by HeapFree().
声明：该表是从一些笔记我已经躺在附近 - 他们可能不是100％正确（或相干）
Disclaimer: the table is from some notes I have lying around - they may not be 100% correct (or coherent).
许多设置值在VC / CRT / src目录/ dbgheap.c定义的：
Many of these values are defined in vc/crt/src/dbgheap.c:
/*
* The following values are non-zero, constant, odd, large, and atypical
* Non-zero values help find bugs assuming zero filled data.
* Constant values are good so that memory filling is deterministic
* (to help make bugs reproducable). Of course it is bad if
* the constant filling of weird values masks a bug.
* Mathematically odd numbers are good for finding bugs assuming a cleared
* lower bit.
* Large numbers (byte values at least) are less typical, and are good
* at finding bad addresses.
* Atypical values (i.e. not too often) are good since they typically
* cause early detection in code.
* For the case of no-man's land and free blocks, if you store to any
* of these locations, the memory integrity checker will detect it.
*
* _bAlignLandFill has been changed from 0xBD to 0xED, to ensure that
* 4 bytes of that (0xEDEDEDED) would give an inaccessible address under 3gb.
*/
static unsigned char _bNoMansLandFill = 0xFD; /* fill no-man's land with this */
static unsigned char _bAlignLandFill = 0xED; /* fill no-man's land for aligned routines */
static unsigned char _bDeadLandFill = 0xDD; /* fill free objects with this */
static unsigned char _bCleanLandFill = 0xCD; /* fill new objects with this */
也有几次当调试运行时将填补使用已知值缓冲区（或缓冲区的部分），例如的std ::字符串松弛太空的分配或传递给 _SECURECRT_FILL_BUFFER_PATTERN A值（ crtdefs.h 定义）。我不知道到底时，刚开始，但它是通过在调试运行时至少VS 2005（VC ++ 8）。
There are also a few times where the debug runtime will fill buffers (or parts of buffers) with a known value, for example the 'slack' space in std::string's allocation or the buffer passed to fread(). Those cases use a value given the name _SECURECRT_FILL_BUFFER_PATTERN (defined in crtdefs.h). I'm not sure exactly when it was introduced, but it was in the debug runtime by at least VS 2005 (VC++8).
最初用来填充这些缓冲区值是0xFD - 用于无人区相同的值。然而，在VS 2008中（VC ++ 9）值更改为 0xFE的。我想这是因为有可能是那里的填充操作会跑过去缓冲区的结束的情况下，例如，如果在缓冲区大小通过呼叫者太大， FREAD（）。在这种情况下，值是0xFD 可能不会触发检测这个溢出，因为如果缓冲区的大小是由只是一个过大，填充值是一样的无人区值用于初始化金丝雀。在无人区没有变化意味着溢出不会被察觉。
Initially the value used to fill these buffers was 0xFD - the same value used for no man's land. However, in VS 2008 (VC++9) the value was changed to 0xFE. I assume that's because there could be situations where the fill operation would run past the end of the buffer, for example if the caller passed in a buffer size that was too large to fread(). In that case, the value 0xFD might not trigger detecting this overrun since if the buffer size was too large by just one, the fill value would be the same as the no man's land value used to initialize that canary. No change in no man's land means the overrun wouldn't be noticed.
因此，填充值是在2008年VS改变，因此这种情况将改变无人区金丝雀，导致检测问题由运行库。
So the fill value was changed in VS 2008 so that such a case would change the no man's land canary, resulting in detection of the problem by the runtime.
正如其他人指出，这些价值观的关键特性之一是与其中的一个值的指针变量间接引用，它会导致访问冲突，因为在一个标准的32位Windows的配置，用户模式地址不会比更高为0x7FFFFFFF
As others have noted, one of the key properties of these values is that is a pointer variable with one of these values is dereferenced, it will result in an access violation, since on a standard 32-bit Windows configuration, user mode addresses will not go higher than 0x7fffffff.
这篇关于什么时候和为什么会操作系统初始化内存0XCD，0xDD等上的malloc /自由/新/删除吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
