問題源自一段簡單的代碼：

    void main()

{

 char *p = new char;

 cin>>p;

 cout<<p[2];

 delete p;

} 


  

在以上代碼中，如果你輸入:abcd，那么如你所望，你會看到"正確"的輸出"c"。但是會有錯誤提示出現：
Debug Error!
Program: test.exe
DAMAGE: after Normal block(#64) at 0x003429f8

更離奇的是，如果將代碼改為如下的代碼：

    void()

{

char *p = new char;

cin>>p;

cout<<p;

delete p;

}


  

如果只輸入一個字符a，那么依然報錯。是不是奇怪，分配了一個字符，輸入了一個字符，那么錯在哪里？ 注意，最開始那行Debug Error!說明這是在Debug編譯模式下才有的提示，如果你換到release頻道，那么此提示不再出現，你成功得到了"c"，仿佛程序一切正常。

一個奇怪的現象是，如果去掉delete p這條語句，這個運行時錯誤消失了，甚至你在debug模式下也看不到這個提示。 問題何在？

以前我遇到過這種情況，分析后歸結為一個結論：在debug模式下系統有一定的機制偵測到內存的非法訪問。然后就放過這個問題。這個結論說了等于沒說，關鍵在于，這種機制的具體運做過程。這次我下了狠心，不入虎穴，焉得虎子。我決定追進源代碼里邊去。 把編譯環境設置成debug模式，很顯然，問題出在delete p上，在這條語句設置斷點，按F5，程序運行到這條語句前自動暫停，然后按F11。

Welcome to the Source Code World!

首先來到 DELOP.CPP 文件中，這個文件短小精悍，只有一個函數

    void __cdecl operator delete(void *p) _THROW0()

{ // free an allocated object

 free(p);

}


  

沒有任何有用的信息，那就繼續追進free（p）里。 不一會，我們追到了 DBGHEAP.C 中，你從文件名可以看出，這是在debug模式下才能進入的文件。

最后在_CRTIMP void __cdecl _free_dbg（void * pUserData, int nBlockUse )中的這條語句

    if (!CheckBytes(pbData(pHead) + pHead->nDataSize, _bNoMansLandFill, nNoMansLandSize))

                _RPT3(_CRT_ERROR, "DAMAGE: after %hs block (#%d) at 0x%08X./n",

                    szBlockUseName[_BLOCK_TYPE(pHead->nBlockUse)],

                    pHead->lRequest,

                    (BYTE *) pbData(pHead)); 


  

前受阻。 是不是覺得這這模塊巨可怕，呵呵，靜下心來，很簡單，因為有if存在，那么CheckBytes（）一定是執行某種檢驗，如果檢驗失敗，調用_RPT3()函數 在MSDN中，對_RPT函數族有這樣的解釋：

Track an application''s progress by generating a debug report (debug version only).

_RPT3的作用就是產生一個錯誤報告。
好了，知道了這一點就足夠了，它對我們來說沒什么意義了。那么只剩下CheckBytes了，深呼吸幾口，好了，讓我們進去吧。

    static int __cdecl CheckBytes(unsigned char * pb, unsigned char bCheck, size_t nSize)

{

        int bOkay = TRUE;

        while (nSize--)

        {

            if (*pb++ != bCheck)

            {

               _RPT3(_CRT_WARN, "memory check error at 0x%08X = 0x%02X, should be 0x%02X./n",

                    (BYTE *)(pb-1),*(pb-1), bCheck);

                bOkay = FALSE;

            }

        }

        return bOkay;

}


  

你看到了，這個函數只調用了_RPT3，再也沒有其他的調用，看來，我們到頭了。 下面是微軟的程序員為這個函數寫的注釋的一部分：

    *Purpose:

*       verify byte range set to proper value

*Return:

*       TRUE - if all bytes in range equal bcheck

*       FALSE otherwise


  

再明顯不過了，這個函數檢驗一定范圍的位是否設定為了正確的值(就是傳進來的那么bCheck），如果正確，返回bOkay=TRUE,否則，返回bOkay=FALSE. 都挖完了，再也沒有任何有用的信息，我們仍舊不知道微軟是如何進行校驗的，眼前依然一片黑暗。如果還有黎明的曙光，那么只能從傳入的參數身上發出，呵呵，它們三肩負著我們的厚望啊。看看第一個參數unsigned char* pb。 if (*pb++ != bCheck)這條語句告訴我們要將pb所指內存地址的指與bCheck比較，那么我們還有最后一線希望： 直接監視內存 。
還記得我們在delete p;前設的斷點嗎？好，讓我們重新開始調試，按F5，從控制臺輸入"abcd"，然后到這條語句前停止了，查看變量p的值，是0x00342c40，那好，打開vc監視內存的窗口memory，我們查看這個地址的值：


此后的內存情況不再用圖片顯示。只用紅色標志的內存表示發生了變化的內存

看到了嗎？你的寶貝"abcd"乖乖地躺在內存中，其后跟了一個0x00，那表示''/0''，字符串結束標志。一切都很正常，到底哪里出錯了？難道是delete p用錯了，而應該用delete[] p？try it,你會發現依然有相同的錯誤。

從這段內存中仍然看不出問題，仿佛一切風平浪靜，其實是我們來晚了，在delete p前，內存早已經發生了翻天覆地的變化。 再一次重新進入程序，這次我們從一開始就監視內存。

00342C40 EE FE EE FE EE FE EE 鉿鉿鉿.
00342C47 FE EE FE EE FE EE FE .

這是char *p = new char,執行前的內存。下面是執行后的:

00342C40 CD FD FD FD FD F0 AD 妄.
00342C47 BA 0D F0 AD BA 0D F0 ..瓠...

看不出什么問題，再往下執行吧：(cin>>p, 這次我們輸入ab）

00342C40 61 62 00 FD FD F0 AD ab. 瓠
00342C47 BA 0D F0 AD BA 0D F0 ..瓠...

ab正確地放進了內存中，而且你可以看到cin還體貼地在ab后為你放了一個''/0''

還是沒有什么問題？再往下走就是cout<<p了，它不會改動內存，再往下就到了delete p，到那時一切都晚了。 沒錯，就是這一步，靜靜的內存中早已經翻江倒海。

還記得static int __cdecl CheckBytes(unsigned char * pb, unsigned char bCheck, size_t nSize)中的bCheck, nSize嗎？ 如果當初你也監視變量的話，會發現bCheck = 253, nSize = 4。這就是這個內存偵測機制的命門。小時候喜歡看武打片，有一部叫做〈鷹爪鐵布衫〉的，當時令我如癡如醉啊，看過的人一定還記得最后殺那老頭的時候是先在他天靈上一拍，接著再在褲襠上捏一把，呵呵，bCheck就是天靈，nSize就是褲襠。

把253轉換為16進制，是什么，沒錯，是FD。呵呵，別忙往下看，想一想，你找到真相了嗎？ 再看一眼char *p = new char執行后的內存，你發現了什么？p指向0x00342c40那個字節的值為CD，這是屬于你的內存，看看后邊跟的是什么，不多不少， 恰恰是4個FD，恰恰是nSize個bCheck！

這個偵測內存非法訪問的機制現在已經被我們開膛破肚了。微軟在你申請的空間后加上四個FD，如果你訪問了你非法訪問內存，那么這些內存的內容將被改變(有一個問題我沒有解決，我不知道FD代表什么，望知道的兄弟教我)，在delete時，將檢查由new產生的''/0''結束符后是否有連續四個字節都是FD，如果有證明沒有發生非法內存訪問，如果沒有，那就該讓_RPT3老兄出馬了。
對于

    char *p = new char;

cin>>p;

cout<<p;

delete p;


  

這段代碼，如果只輸入一個字符a，cin>>p執行后的內存為

00342C40 61 00 FD FD FD F0 AD a. .
00342C47 BA 0D F0 AD BA 0D F0 ..瓠...

雖然你只用了你申請的內存，但是cin為了討好你給你加那個''/0''，覆蓋了一個FD，這樣，delete時照樣報錯，如果你這樣做

    char *p = new char[2];
  

那么cin>>p后內存為

00342C40 61 00 FD FD FD FD AD a. .
00342C47 BA 0D F0 AD BA 0D F0 ..瓠...

那么程序將不會報錯。 四個FD就是內存的生死疆界，超過這個疆界，呵呵，聽見遠方傳來的崩潰的聲音了嗎？ 到此，一切真相大白，山高月小，水落石出！

（尾聲：以上所有內容皆來自筆者獨立分析，其中難免有錯，更甚者，也許我大錯特錯，壓根就不是這樣的機制。如果你發現其中有不正確的地方，請指出，謝謝，在下感激不盡）。

生死疆界--- 在new與delete之間