2008-09-24 81 views
185

在Visual Studio中,我們都有「baadf00d」,在運行時在C++中檢查調試器中的變量時看到「CC」和「CD」。在Visual Studio C++中,內存分配表示是什麼?

據我所知,「CC」處於DEBUG模式,僅用於指示內存何時已經new()或alloc()和單位化。 「CD」表示刪除或釋放內存。我只在RELEASE版本中看過「baadf00d」(但我可能是錯的)。

有一段時間,我們陷入了內存泄漏,緩衝區溢出等情況,這些信息派上用場。

有人會指出什麼時候以什麼模式將內存設置爲用於調試目的的可識別字節模式?

+0

[時候和爲什麼會操作系統初始化內存0XCD,0xDD等上的malloc /自由/新/刪除?](HTTP:// stackoverflow.com/q/370195/995714) – 2016-02-23 05:56:06

+0

@LưuVĩnhPhúc:這不是操作系統,它是調試器。 「D」(如在0xCD和0xDD上)用於調試(即,malloc_dbg是通過malloc調用的內容,如https://msdn.microsoft.com/en-us/library/aa270812(v=vs.60)中所述)的.aspx)。我相信它還會在堆棧周圍添加fence/posts以跟蹤緩衝區溢出。當你有一個雙重刪除或多重自由(或者甚至可能調用delete而不是delete [])和懸掛的指針(當你檢查數據時,它是「0xDD」)時,捕獲問題非常有用。 (或者當未初始化的堆顯示0xCD時) – HidekiAI 2016-02-23 18:19:21

+0

我沒有說它是操作系統。這是另一個提問不正確的地方 – 2016-02-23 23:40:32

回答

258

此鏈接提供了更多信息:

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 
100

有實際上是相當多的加入到調試分配有用的信息。此表是更完整:

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 
0x00 +0  0xBAADF00D 0xCDCDCDCD  0xDDDDDDDD 0xFEEEFEEE  The 8 bytes you wanted 
0x04 +4  0xBAADF00D 0xCDCDCDCD  0xDDDDDDDD 0xFEEEFEEE  The 8 bytes you wanted 
0x08 +8  0xBAADF00D 0xFDFDFDFD  0xDDDDDDDD 0xFEEEFEEE  No mans land 
0x0C +12 0xBAADF00D 0xBAADF00D  0xDDDDDDDD 0xFEEEFEEE  Win32 heap allocations are rounded up to 16 bytes 
0x10 +16 0xABABABAB 0xABABABAB  0xABABABAB 0xFEEEFEEE  Win32 heap bookkeeping 
0x14 +20 0xABABABAB 0xABABABAB  0xABABABAB 0xFEEEFEEE  Win32 heap bookkeeping 
0x18 +24 0x00000010 0x00000010  0x00000010 0xFEEEFEEE  Win32 heap bookkeeping 
0x1C +28 0x00000000 0x00000000  0x00000000 0xFEEEFEEE  Win32 heap bookkeeping 
0x20 +32 0x00090051 0x00090051  0x00090051 0xFEEEFEEE  Win32 heap bookkeeping 
0x24 +36 0xFEEE0400 0xFEEE0400  0xFEEE0400 0xFEEEFEEE  Win32 heap bookkeeping 
0x28 +40 0x00320400 0x00320400  0x00320400 0xFEEEFEEE  Win32 heap bookkeeping 
0x2C +44 0x00320400 0x00320400  0x00320400 0xFEEEFEEE  Win32 heap bookkeeping 
1

特別是關於0xCC0xCD,這些都是從20世紀80年代折戟英特爾8088/8086處理器指令文物。 0xCCsoftware interrupt操作碼INT0xCD的特例。特殊的單字節版本0xCC允許程序生成中斷3

雖然軟件中斷數,原則上,隨心所欲,INT 3傳統上用於調試破breakpoint功能,它仍然是這一天的約定。每當調試器啓動時,它都會安裝一箇中斷處理程序INT 3,以便當該代碼執行時,調試器將被觸發。通常它會暫停當前正在運行的編程並顯示交互提示。

通常,x86 INT操作碼是兩個字節:0xCD後跟所需的0-255中斷號。現在儘管您可以爲發行INT 3,但英特爾決定添加一個特殊版本 - 0xCC,但沒有附加字節 - 因爲操作碼必須只有一個字節,以便充當未使用內存的可靠「填充字節」。

這裏的要點是,如果處理器錯誤跳轉到內存中,並且不包含任何預期的指令,則允許優雅恢復。多字節指令不適合這種用途,因爲錯誤的跳轉可能會導致任何可能的字節偏移,因此它必須繼續使用正確形成的指令流。顯然,單字節操作碼對此很平凡,但也可能有一些奇怪的例外:例如,考慮填充序列0xCDCDCDCD(本頁也提到),我們可以看到它是相當可靠的,因爲無論在哪裏(除了最後填充的字節除外),CPU可以繼續執行有效的雙字節 x86指令CD CD,在這種情況下用於生成軟件中斷205(0xCD)。

怪異仍然,而CD CC CD CC是100%可解釋 - 給任一INT 3INT 204 --the序列CC CD CC CD是較不可靠的,只有75%的如所示的,但作爲一個int大小的存儲器填料重複時通常99.99%。

page from contemporaneous 8088/8086 instruction set manual showing INT instruction
宏彙編參考,1987