今天，在運行目前正在維護的產品后，我發現產品在跑完個別的測試用例后，出現了大量的內存泄漏。從visual studio 2008
的輸出中看不到具體是哪個文件的new
操作引起，在DEBUG
版本中看不到是由哪個new
分配的內存泄漏的原因是文件中沒有如下的宏。
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
由于項目中的文件較多，如果到一個一個文件中去找，那是件枯燥而且乏味的工作， 而且難保不會有遺漏。所以我編寫了腳本來報告沒有這幾句的文件。
通過在文件中加上了上述的宏，我再次重新運行剛才產生內存泄漏的測試用例。這次我定位了泄漏的內存分配語句。所以為了調試上的方便，我們應保證文件中有如上的宏。找到了相關的分配語句就離解決這個錯誤近了，現在就是要找出遺漏的釋放點。
為了使用我以前安裝的共享版內存泄漏檢測工具，我將系統的時間改成6月份。可惜還是提示過了試用期不讓使用，所以還得靠自己。通過查閱代碼，找出了幾個可疑點，分別加上了恰當的語句，按一下build 后，剛巧有事就離開了。回來后發現看看沒有編譯錯誤，于是再測試用例，結果還是出現泄漏。于是我加上調試斷點來分析，可是程序根本不在斷點處停止。這讓我著實驚訝，難道程序并不經過這些斷點？ 再放置幾個斷點，依然不停住，最后就在InitInstance()函數中放一斷點，可還是不停住。這時我才恍然大悟這個exe文件與代碼不一致。于是改回系統時間，重新build。再次運行，程序在斷點處停住，運行相應的測試用例，也不再有內存泄漏。
在這個過程中，由于visual studio的編譯行為所采用的時間比較來決定編譯的行為及本人的粗心讓我浪費了一些時間和精力。這也提示我們在設計軟件時，對于優化行為應多加考慮，行為的優化是否符合了用戶的企圖，如果與用戶的動作不符合，則應給用戶提示并得到用戶的指示。