首页 文章

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

提问于
浏览
196

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

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

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

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

3 回答

  • 106

    此链接有更多信息:

    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
    
  • 3

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

    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
    
  • 279

    特别是关于 0xCC0xCD ,这些是20世纪80年代 Intel 8088/8086 处理器指令集的遗物 . 0xCCsoftware interrupt操作码INT 0xCD 的特例 . 特殊的单字节版本 0xCC 允许程序生成 interrupt 3 .

    尽管软件中断号原则上是任意的,但 INT 3 传统上用于 debugger breakbreakpoint函数,这一惯例至今仍然存在 . 无论何时启动调试器,它都会为 INT 3 安装一个中断处理程序,以便在执行该操作码时,将触发调试器 . 通常,它会暂停当前正在运行的编程并显示交互式提示 .

    通常,x86 INT 操作码是两个字节: 0xCD 后跟0-255之间的所需中断号 . 现在虽然您可以为 INT 3 发出 0xCD 0x03 ,但英特尔决定添加一个特殊版本 0xCC 而没有额外的字节 - 因为操作码必须只有一个字节才能作为未使用内存的可靠'fill byte' .

    这里的要点是,如果处理器错误地跳转到不包含任何预期指令的内存,则允许正常恢复 . 多字节指令不适用于此目的,因为错误的跳转可能落在任何可能的字节偏移处,在那里它必须继续正确形成的指令流 .

    显然,单字节操作码对此非常简单,但也可能存在奇怪的例外:例如,考虑到填充序列 0xCDCDCDCD (本页也提到过),我们可以看到它相当可靠,因为无论instruction pointer落在哪里(除了最后填充的字节之外,CPU可以继续执行有效的 two-byte x86指令 CD CD ,在这种情况下用于生成软件中断205(0xCD) .

    Weirder仍然,而 CD CC CD CC 是100%可解释的 - 给出 INT 3INT 204 - 序列 CC CD CC CD 不太可靠,只有75%如图所示,但通常99.99%重复作为int大小的内存填充 .

    page from contemporaneous 8088/8086 instruction set manual showing INT instruction

    Macro Assembler Reference,1987

相关问题