空穴來風

　　BoundsChecker采用一種被稱為 Code Injection的技術，來截獲對分配內存和釋放內存的函數的調用。簡單地說，當你的程序開始運行時，BoundsChecker的DLL被自動載入進程的地址空間（這可以通過system-level的Hook實現），然后它會修改進程中對內存分配和釋放的函數調用，讓這些調用首先轉入它的代碼，然后再執行原來的代碼。BoundsChecker在做這些動作的時，無須修改被調試程序的源代碼或工程配置文件，這使得使用它非常的簡便、直接。

　　這里我們以malloc函數為例，截獲其他的函數方法與此類似。

　　需要被截獲的函數可能在DLL中，也可能在程序的代碼里。比如，如果靜態連結C-Runtime Library，那么malloc函數的代碼會被連結到程序里。為了截獲住對這類函數的調用，BoundsChecker會動態修改這些函數的指令。

　　以下兩段匯編代碼，一段沒有BoundsChecker介入，另一段則有BoundsChecker的介入：
以下這一段代碼有BoundsChecker介入：

　　當BoundsChecker介入后，函數malloc的前三條匯編指令被替換成一條jmp指令，原來的三條指令被搬到地址01F41EC8處了。當程序進入malloc后先jmp到01F41EC8，執行原來的三條指令，然后就是BoundsChecker的天下了。大致上它會先記錄函數的返回地址（函數的返回地址在stack上，所以很容易修改），然后把返回地址指向屬于BoundsChecker的代碼，接著跳到malloc函數原來的指令，也就是在00403c15的地方。當malloc函數結束的時候，由于返回地址被修改，它會返回到BoundsChecker的代碼中，此時BoundsChecker會記錄由malloc分配的內存的指針，然后再跳轉到到原來的返回地址去。

　　如果內存分配/釋放函數在DLL中，BoundsChecker則采用另一種方法來截獲對這些函數的調用。BoundsChecker通過修改程序的DLL Import Table讓table中的函數地址指向自己的地址，以達到截獲的目的。

　　截獲住這些分配和釋放函數，BoundsChecker就能記錄被分配的內存或資源的生命周期。接下來的問題是如何與源代碼相關，也就是說當BoundsChecker檢測到內存泄漏，它如何報告這塊內存塊是哪段代碼分配的。答案是調試信息（Debug Information）。當我們編譯一個Debug版的程序時，編譯器會把源代碼和二進制代碼之間的對應關系記錄下來，放到一個單獨的文件里(.pdb)或者直接連結進目標程序，通過直接讀取調試信息就能得到分配某塊內存的源代碼在哪個文件，哪一行上。使用Code Injection和Debug Information，使BoundsChecker不但能記錄呼叫分配函數的源代碼的位置，而且還能記錄分配時的Call Stack，以及Call Stack上的函數的源代碼位置。這在使用像MFC這樣的類庫時非常有用，以下我用一個例子來說明：

當調用ShowYItemMenu()時，我們故意造成HMENU的泄漏。但是，對于BoundsChecker來說被泄漏的HMENU是在class CMenu::CreatePopupMenu()中分配的。假設的你的程序有許多地方使用了CMenu的CreatePopupMenu()函數，如CMenu::CreatePopupMenu()造成的，你依然無法確認問題的根結到底在哪里，在ShowXItemMenu()中還是在ShowYItemMenu()中，或者還有其它的地方也使用了CreatePopupMenu()？有了Call Stack的信息，問題就容易了。BoundsChecker會如下報告泄漏的HMENU的信息：
　　
這里省略了其他的函數調用

如此，我們很容易找到發生問題的函數是ShowYItemMenu()。當使用MFC之類的類庫編程時，大部分的API調用都被封裝在類庫的class里，有了Call Stack信息，我們就可以非常容易的追蹤到真正發生泄漏的代碼。

　　記錄Call Stack信息會使程序的運行變得非常慢，因此默認情況下BoundsChecker不會記錄Call Stack信息?？梢园凑找韵碌牟襟E打開記錄Call Stack信息的選項開關：

　　1. 打開菜單：BoundsChecker|Setting…

　　2. 在Error Detection頁中，在Error Detection Scheme的List中選擇Custom

　　3. 在Category的Combox中選擇 Pointer and leak error check

　　4. 鉤上Report Call Stack復選框

　　5. 點擊Ok

　　基于Code Injection，BoundsChecker還提供了API Parameter的校驗功能，memory over run等功能。這些功能對于程序的開發都非常有益。由于這些內容不屬于本文的主題，所以不在此詳述了。

　　盡管BoundsChecker的功能如此強大，但是面對隱式內存泄漏仍然顯得蒼白無力。所以接下來我們看看如何用Performance Monitor檢測內存泄漏。

　　使用Performance Monitor檢測內存泄漏

　　NT的內核在設計過程中已經加入了系統監視功能，比如CPU的使用率，內存的使用情況，I/O操作的頻繁度等都作為一個個Counter，應用程序可以通過讀取這些Counter了解整個系統的或者某個進程的運行狀況。Performance Monitor就是這樣一個應用程序。

　　為了檢測內存泄漏，我們一般可以監視Process對象的Handle Count，Virutal Bytes 和Working Set三個Counter。Handle Count記錄了進程當前打開的HANDLE的個數，監視這個Counter有助于我們發現程序是否有Handle泄漏；Virtual Bytes記錄了該進程當前在虛地址空間上使用的虛擬內存的大小，NT的內存分配采用了兩步走的方法，首先，在虛地址空間上保留一段空間，這時操作系統并沒有分配物理內存，只是保留了一段地址。然后，再提交這段空間，這時操作系統才會分配物理內存。所以，Virtual Bytes一般總大于程序的Working Set。監視Virutal Bytes可以幫助我們發現一些系統底層的問題; Working Set記錄了操作系統為進程已提交的內存的總量，這個值和程序申請的內存總量存在密切的關系，如果程序存在內存的泄漏這個值會持續增加，但是Virtual Bytes卻是跳躍式增加的。

　　監視這些Counter可以讓我們了解進程使用內存的情況，如果發生了泄漏，即使是隱式內存泄漏，這些Counter的值也會持續增加。但是，我們知道有問題卻不知道哪里有問題，所以一般使用Performance Monitor來驗證是否有內存泄漏，而使用BoundsChecker來找到和解決。

　　當Performance Monitor顯示有內存泄漏，而BoundsChecker卻無法檢測到，這時有兩種可能：第一種，發生了偶發性內存泄漏。這時你要確保使用Performance Monitor和使用BoundsChecker時，程序的運行環境和操作方法是一致的。第二種，發生了隱式的內存泄漏。這時你要重新審查程序的設計，然后仔細研究Performance Monitor記錄的Counter的值的變化圖，分析其中的變化和程序運行邏輯的關系，找到一些可能的原因。這是一個痛苦的過程，充滿了假設、猜想、驗證、失敗，但這也是一個積累經驗的絕好機會。

　　總結

　　內存泄漏是個大而復雜的問題，即使是Java和.Net這樣有Gabarge Collection機制的環境，也存在著泄漏的可能，比如隱式內存泄漏。由于篇幅和能力的限制，本文只能對這個主題做一個粗淺的研究。其他的問題，比如多模塊下的泄漏檢測，如何在程序運行時對內存使用情況進行分析等等，都是可以深入研究的題目。如果您有什么想法，建議或發現了某些錯誤，歡迎和我交流。