编译器何时以及为什么会在 malloc/free/new/delete 上将内存初始化为 0xCD、0xDD 等？

Question

我知道编译器有时会使用某些模式初始化内存，例如 0xCD 和 0xDD 。我想知道的是 何时 以及 为什么 会发生这种情况。

什么时候

这是特定于使用的编译器吗？

malloc/new 和 free/delete 在这方面的工作方式相同吗？

它是特定于平台的吗？

会不会出现在其他操作系统上，比如 Linux 或者 VxWorks ？

为什么

我的理解是这只发生在 Win32 调试配置中，它用于检测内存溢出并帮助编译器捕获异常。

你能给出任何实际例子来说明这个初始化是如何有用的吗？

我记得读过一些东西（可能在 Code Complete 2 中）说在分配内存时最好将内存初始化为已知模式，并且某些模式会在 Win32 中触发中断，这将导致调试器中显示异常.

这有多便携？

原文由 LeopardSkinPillBoxHat 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

微软编译器在为调试模式编译时用于各种无主/未初始化内存的快速总结（支持可能因编译器版本而异）：

 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.
                         It is 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 identify 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% 正确（或连贯）。

其中许多值在 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 reproducible).  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::string 分配中的“松弛”空间或传递给的缓冲区 fread() 。这些情况使用一个名为 _SECURECRT_FILL_BUFFER_PATTERN 的值（在 crtdefs.h 中定义）。我不确定它是何时引入的，但它至少在 VS 2005 (VC++8) 的调试运行时中。

最初，用于填充这些缓冲区的值是 0xFD - 与无人区使用的值相同。但是，在 VS 2008 (VC++9) 中，该值更改为 0xFE 。我认为这是因为在某些情况下，填充操作可能会超出缓冲区的末尾，例如，如果调用者传入的缓冲区大小对于 fread() 来说太大。在这种情况下，值 0xFD 可能不会触发检测此溢出，因为如果缓冲区大小仅大 1，则填充值将与用于初始化该金丝雀的无人土地值相同。无人区没有变化意味着超支不会被注意到。

所以在 VS 2008 中更改了填充值，这样这种情况就会改变无人区金丝雀，导致运行时检测到问题。

正如其他人所指出的，这些值的关键属性之一是，如果取消引用具有这些值之一的指针变量，则会导致访问冲突，因为在标准 32 位 Windows 配置中，用户模式地址不会高于 0x7fffffff。

原文由 Michael Burr 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 2

这是特定于使用的编译器吗？

实际上，它几乎总是运行时库（如 C 运行时库）的一个特性。运行时通常与编译器密切相关，但您可以交换一些组合。

我相信在 Windows 上，调试堆（HeapAlloc 等）也使用特殊的填充模式，这些模式不同于来自调试 C 运行时库中的 malloc 和 free 实现的填充模式。所以它也可能是一个操作系统特性，但大多数时候，它只是语言运行时库。

malloc/new 和 free/delete 在这方面的工作方式是否相同？

new 和 delete 的内存管理部分通常使用 malloc 和 free 实现，因此 new 和 delete 分配的内存 通常 具有相同的功能。

它是特定于平台的吗？

详细信息是特定于运行时的。使用的实际值通常被选择为不仅在查看十六进制转储时看起来不寻常且明显，而且设计为具有可能利用处理器功能的某些属性。例如，经常使用奇数值，因为它们可能导致对齐错误。使用较大的值（而不是 0），因为如果您循环到未初始化的计数器，它们会导致令人惊讶的延迟。在 x86 上，0xCC 是 int 3 指令，所以如果你执行一个未初始化的内存，它会陷入陷阱。

会不会出现在其他操作系统上，例如 Linux 或 VxWorks？

它主要取决于您使用的运行时库。

你能给出任何实际例子来说明这个初始化是如何有用的吗？

我在上面列出了一些。选择这些值通常是为了增加在使用无效内存部分执行某些操作时发生异常情况的机会：长时间延迟、陷阱、对齐错误等。堆管理器有时还使用特殊填充值来处理分配之间的间隙。如果这些模式发生变化，它就会知道某处存在错误写入（如缓冲区溢出）。

我记得读过一些东西（可能在 Code Complete 2 中），在分配内存时最好将内存初始化为已知模式，并且某些模式将触发 Win32 中的中断，这将导致调试器中显示异常。

这有多便携？

编写 Solid Code （可能还有 Code Complete ）讨论了在选择填充模式时要考虑的事项。我在这里提到了其中的一些，维基百科上关于 Magic Number (programming) 的文章也对它们进行了总结。一些技巧取决于您使用的处理器的具体情况（例如它是否需要对齐的读取和写入以及哪些值映射到将捕获的指令）。其他技巧，例如使用在内存转储中突出的大值和不寻常的值，更便于移植。

原文由 Adrian McCarthy 发布，翻译遵循 CC BY-SA 4.0 许可协议