在Visual Studio C++中,内存分配表示是什么？

在Visual Studio中,我们都有"baadf00d",在运行时在C++中检查调试器中的变量时看到过"CC"和"CD".

根据我的理解,"CC"仅处于DEBUG模式,以指示内存何时是new()或alloc()并且是单元化的."CD"代表删除或免费内存.我在RELEASE版本中只看过"baadf00d"(但我可能错了).

偶尔会遇到内存泄漏,缓冲区溢出等问题,这些信息会派上用场.

是否有人能够指出何时以何种模式将内存设置为可识别的字节模式以进行调试？

1> Mark Ingram..：

---

此链接有更多信息:

http://en.wikipedia.org/wiki/Magic_number_(programming)

* 0xABABABAB : Used by Microsoft's HeapAlloc() to mark "no man's land" guard bytes after allocated heap memory
* 0xABADCAFE : A startup to this value to initialize all free 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 is 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
* 0xDDDDDDDD : Used by Microsoft's C++ debugging heap to mark freed 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

---

@AndersonGreen当然这是故意的.它被称为[hexspeak](http://en.wikipedia.org/wiki/Hexspeak).

---

当我们在日子里做了一些低级(操作系统内核)编程时,我们曾经使用过C0CAC01A ...;)

---

在这里,我看到'BAADF00D`(糟糕的食物),`BEEFCACE`(牛肉蛋糕),`BAADCAB1E`(坏电缆),`BADCAFE`(坏咖啡馆)和'DEADDEAD'(死了).这是故意的吗？

---

`0xDEADBEEF`,`0xC0EDBABE`也是经典,即使它们不属于MS的白话

---

作为Paul McCartney的粉丝,我喜欢'BEA71E5`

2> John Dibling..：

---

实际上,调试分配中添加了许多有用的信息.这个表更完整:

http://www.nobugs.org/developer/win32/debug_crt_heap.html#table

Address  Offset After HeapAlloc() After malloc() During free() After HeapFree() Comments
0x00320FD8  -40    0x01090009    0x01090009     0x01090009    0x0109005A     Win32 heap info
0x00320FDC  -36    0x01090009    0x00180700     0x01090009    0x00180400     Win32 heap info
0x00320FE0  -32    0xBAADF00D    0x00320798     0xDDDDDDDD    0x00320448     Ptr to next CRT heap block (allocated earlier in time)
0x00320FE4  -28    0xBAADF00D    0x00000000     0xDDDDDDDD    0x00320448     Ptr to prev CRT heap block (allocated later in time)
0x00320FE8  -24    0xBAADF00D    0x00000000     0xDDDDDDDD    0xFEEEFEEE     Filename of malloc() call
0x00320FEC  -20    0xBAADF00D    0x00000000     0xDDDDDDDD    0xFEEEFEEE     Line number of malloc() call
0x00320FF0  -16    0xBAADF00D    0x00000008     0xDDDDDDDD    0xFEEEFEEE     Number of bytes to malloc()
0x00320FF4  -12    0xBAADF00D    0x00000001     0xDDDDDDDD    0xFEEEFEEE     Type (0=Freed, 1=Normal, 2=CRT use, etc)
0x00320FF8  -8     0xBAADF00D    0x00000031     0xDDDDDDDD    0xFEEEFEEE     Request #, increases from 0
0x00320FFC  -4     0xBAADF00D    0xFDFDFDFD     0xDDDDDDDD    0xFEEEFEEE     No mans land
0x00321000  +0     0xBAADF00D    0xCDCDCDCD     0xDDDDDDDD    0xFEEEFEEE     The 8 bytes you wanted
0x00321004  +4     0xBAADF00D    0xCDCDCDCD     0xDDDDDDDD    0xFEEEFEEE     The 8 bytes you wanted
0x00321008  +8     0xBAADF00D    0xFDFDFDFD     0xDDDDDDDD    0xFEEEFEEE     No mans land
0x0032100C  +12    0xBAADF00D    0xBAADF00D     0xDDDDDDDD    0xFEEEFEEE     Win32 heap allocations are rounded up to 16 bytes
0x00321010  +16    0xABABABAB    0xABABABAB     0xABABABAB    0xFEEEFEEE     Win32 heap bookkeeping
0x00321014  +20    0xABABABAB    0xABABABAB     0xABABABAB    0xFEEEFEEE     Win32 heap bookkeeping
0x00321018  +24    0x00000010    0x00000010     0x00000010    0xFEEEFEEE     Win32 heap bookkeeping
0x0032101C  +28    0x00000000    0x00000000     0x00000000    0xFEEEFEEE     Win32 heap bookkeeping
0x00321020  +32    0x00090051    0x00090051     0x00090051    0xFEEEFEEE     Win32 heap bookkeeping
0x00321024  +36    0xFEEE0400    0xFEEE0400     0xFEEE0400    0xFEEEFEEE     Win32 heap bookkeeping
0x00321028  +40    0x00320400    0x00320400     0x00320400    0xFEEEFEEE     Win32 heap bookkeeping
0x0032102C  +44    0x00320400    0x00320400     0x00320400    0xFEEEFEEE     Win32 heap bookkeeping

3> Glenn Slayde..：

---

关于0xCC和0xCD特别是，这些是从遗物英特尔8088 / 8086在1980处理器指令集回来。0xCC是软件中断操作码 的特例。特殊的单字节版本允许程序生成中断3。INT 0xCD0xCC

尽管从理论上讲，软件中断号是任意的，INT 3但传统上它是用于调试器的break或breakpoint函数的，这一约定一直存在至今。每当调试器启动时，它都会安装一个中断处理程序，INT 3以便在执行该操作码时将触发调试器。通常，它将暂停当前正在运行的程序并显示交互式提示。

通常，x86 INT操作码为两个字节：0xCD后跟0-255之间的所需中断号。现在，尽管您可以提出0xCD 0x03要求INT 3，但英特尔还是决定添加一个特殊版本- 0xCC不增加任何字节-因为操作码必须仅为一个字节，才能用作未使用内存的可靠“填充字节”。

这里的重点是，如果处理器错误地跳入不包含任何预期指令的内存，则可以进行正常恢复。多字节指令不适合此目的，因为错误的跳转可能落在任何可能的字节偏移处，在这种情况下，它必须继续以正确形成的指令流继续。

显然，一字节操作码对此很简单，但是也可能有一些古怪的例外：例如，考虑到填充序列0xCDCDCDCD（也在本页上提到），我们可以看到它是相当可靠的，因为无论指令指针位于何处（除了可能的最后一个填充字节之外），CPU可以继续执行有效的两个字节的 x86指令CD CD，在这种情况下，会产生软件中断205（0xCD）。

尽管如此，Weirder仍然CD CC CD CC是100％可以解释的-给出一个INT 3或一个INT 204序列CC CD CC CD的可靠性较差，如图所示仅为75％，但作为整数大小的存储填充物重复时通常为99.99％。

_{宏汇编程序参考，1987年}