起因是這樣的，為了方便讀取RO裡的素材，我在OPenRO里加入了一個第三方庫，他的作用主要就是負責提取RO素材資料，並把他們放在heap裡，程式退出他會自動釋放。

但是莫名其妙的問題隨之而來了：每次程式退出都會彈窗提示：“******，其原因可能是堆被損壞，這也說明****載入的Dll可能有問題”。看見這個，我第一反應是Dll裡分配的記憶體在程式裡釋放時，Dll與exe使用了不同的C執行時庫。但是我使用的這個第三方庫根本就是一個靜態lib啊，而且使用的C執行時庫版本絕對是一樣的。

我就鬱悶了，剩下只有一種解釋，這個lib有問題，可能其中的處理會導致堆損壞，比如越界寫入，delete不存在的記憶體等。於是我就抱著找出這個BUG的信念，從頭到尾把這個庫給看了一遍。

一天完了，一無所獲。

第二天，發現了更詭異的問題，我用這個第三方庫載入了不同的素材，程式退出依然彈窗提示，但是從除錯堆疊視窗看到的結果卻不一樣，顯示的是我自己的模組堆損壞。這樣，我又把自己的程式檢查了一遍，還是沒發現問題。。。（其實後來其實發現這個問題也是理所當然，因為整個堆損壞了嘛，可能覆蓋了其他記憶體塊）

我開始懷疑是我WIN7下不相容VS2005的問題。又難得轉成VS2008，正準備放棄這個BUG待以後解決時，採用了Google到的一個方法，在程式程式碼中加入：

_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_DELAY_FREE_MEM_DF | _CRTDBG_CHECK_EVERY_1024_DF | _CRTDBG_CHECK_CRT_DF);

_CrtSetReportMode(_CRT_WARN, _CRTDBG_MODE_DEBUG | _CRTDBG_MODE_WNDW);

這樣程式就回提示你程式碼哪裡的操作會導致堆損壞，比如越界等。雖然我試驗提示的區域還是反彙編，但是從除錯堆疊我找到了堆損壞的源頭。看了差點沒把我氣死，這個錯誤在金山實習時就被BOSS指出來過，雖然當時我的程式碼並沒有觸發這個BUG。。。。

void SomeFunction(const char* str);

std::string str;
SomeFunction(str.c_str());

看似非常正常的一段程式碼，但是，顯然，str.c_str()的生存期是由str管理的，一旦str銷燬，c_str()也就銷燬了，如果SomeFunction繼續處理這個指標，那就不曉得損壞的是堆裡面的哪塊記憶體了，結果就是導致一系列詭異的BUG，讓你很難找到錯誤的源頭。所以，建議，使用string的c_str()函式時，需要非常謹慎。

發現經常DEBUG，有些問題還是很通用的，所以建立一個DEBUG標籤，記錄一些DEBUG經驗。