C++內存泄漏檢測工具

1.VC自帶的CRT:_CrtCheckMemory 調試器和 CRT 調試堆函數

1.1用法：

/************************************************************************
 *   環境：VC6.0
 *   程序功能：CRT 檢測內存泄漏  
 *   創建：  2014/3/20
 *   版本號：1.0
 ************************************************************************/
#define CRTDBG_MAP_ALLOC
#include 
 
<stdlib.h>
#include <crtdbg.h>
#include <iostream>  
#include <stdio.h>  
using namespace std;   
int main()
{  
　　int *p=(int*)malloc(sizeof(int));
　　*p=6;
　　cout<<*p<<endl;
　　free(p);
　　p=NULL;
　　_CrtDumpMemoryLeaks();//註意這條語句的擺放位置，因為這會直接影響到你的判斷結果
　　return 0
 
;  
}  

F5運行即可

1.2原理

在使用Debug版的malloc分配內存時，malloc會在內存塊的頭中記錄分配該內存的文件名及行號。當程序退出時CRT會在main()函數返回之後做一些清理工作，這個時候來檢查調試堆內存，如果仍然有內存沒有被釋放，則一定是存在內存泄漏。從這些沒有被釋放的內存塊的頭中，就可以獲得文件名及行號。

1.3缺點

只能檢測出內存泄漏及其泄漏點的文件名和行號，但是並不知道泄漏究竟是如何發生的，並不知道該內存分配語句是如何被執行到的。

CRT的使用詳見：http://blog.sina.com.cn/s/blog_4012aec7010085jo.html

附加：任務管理器---->性能------>內存

若運行程序時，內存使用一直增加，則程序發生內存泄漏。

2.bounds checker

2.1簡介

BoundsChecker 是一個Run-Time錯誤檢測工具，它主要定位程序在運行時期發生的各種錯誤。BoundsChecker能檢測的錯誤包括：

1、指針操作和內存、資源泄露錯誤，比如：

1）內存泄露；

內存操作方面的錯誤，比如：

內存讀、寫溢出；

使用未初始化的內存。

2）資源泄露；

3）對指針變量的錯誤操作。

2.2安裝

先安裝BoundsChecker軟件，安裝完成之後，會在VC++6.0環境中有一個欄目的標題就是BoundsChecker。

2.3使用

使用BoundsChecker對程序的運行時錯誤進行檢測，有兩種使用模式可供選擇。一種模式叫做ActiveCheck，一種模式叫做FinalCheck。下面分別進行介紹。

2.3.1ActiveCheck

ActiveCheck是BoundsChecker提供的一種方便、快捷的錯誤檢測模式，它能檢測的錯誤種類有限，只包括：內存泄露錯誤、資源泄露錯誤、API函數使用錯誤。

要想使用ActiveCheck模式來檢測程序的運行時錯誤，只需在VC++集成開發環境中打開BoundsChecker功能，然後從調試狀態運行程序即可。此時ActiveCheck會在後臺自動運行，隨時檢測程序是否發生了錯誤。

2.3.2FinalCheck

FinalCheck具有BoundsChecker提供的所有檢錯功能。FinalCheck 是ActiveCheck的超集，它除了能夠檢測出ActiveCheck能夠檢測出的錯誤，還能發現很多 ActiveCheck 不能檢測到的錯誤，包括：指針操作錯誤、內存操作溢出、使用未初始化的內存等等，並且，對於ActiveCheck能檢測出的錯誤，FinalCheck能夠給出關於錯誤更詳細的信息。所以，我們可以把FinalCheck認為是ActiveCheck的功能增強版。我們付出的代價是：程序的運行速度會變慢，有時甚至會變的很慢。

要 想在FinalCheck 模式下測試程序，不能使用VC++集成開發環境提供的編譯連接器來構造程序，而必須要使用BoundsChecker提供的編譯連接器來編譯連接程序。當 BoundsChecker的編譯連接器編譯連接程序時，會向程序中插裝一些錯誤檢測代碼，這也就是FinalCheck能夠比ActiveCheck找 到更多錯誤的原因。

詳見鏈接：http://hi.baidu.com/anglecloudy/item/0773ab27b7d25a3394f62bcf

3.Visual Leak Detector

3.1簡介

Visual Leak Detector是一款用於Visual C++的免費的內存泄露檢測工具。可以在http://www.codeproject.com/tools/visualleakdetector.asp 下載到。相比較其它的內存泄露檢測工具，它在檢測到內存泄漏的同時，還具有如下特點：

1、 可以得到內存泄漏點的調用堆棧，如果可以的話，還可以得到其所在文件及行號；

2、 可以得到泄露內存的完整數據；

3、 可以設置內存泄露報告的級別；

4、 它是一個已經打包的lib，使用時無須編譯它的源代碼。而對於使用者自己的代碼，也只需要做很小的改動；

5、 他的源代碼使用GNU許可發布，並有詳盡的文檔及註釋。對於想深入了解堆內存管理的讀者，是一個不錯的選擇。

3.2 使用

安裝：首先從網站上下載zip包，解壓之後得到vld.h, vldapi.h, vld.lib, vldmt.lib, vldmtdll.lib, dbghelp.dll等文件。將.h文件拷貝到Visual C++的默認include目錄下，將.lib文件拷貝到Visual C++的默認lib目錄下，便安裝完成了。因為版本問題，如果使用windows 2000或者以前的版本，需要將dbghelp.dll拷貝到你的程序的運行目錄下，或其他可以引用到的目錄。

/************************************************************************
*   環境：VC6.0
*   程序功能：使用isual Leak Detector 檢測內存泄漏
*   創建：  2014/3/28
*   版本號：1.0
************************************************************************/
#include <vld.h>
#include <stdlib.h>
#include <stdio.h>

void f()
{
    int *p = new int(0x12345678);
    printf("p=%08x, ", p);
    //delete p;
}

int main() 
{  
    f();
   return 0;
}  

編譯運行後，在標準輸出窗口得到：

p=003a89c0

在Visual C++的Output窗口得到：

第二行表示57號塊有4字節的內存泄漏，地址為0x003A89C0，根據程序控制臺的輸出，可以知道，該地址為指針p。程序的第7行，f()函數裏，在該地址處分配了4字節的堆內存空間，並賦值為0x12345678，這樣在報告中，我們看到了這4字節同樣的內容。

對於每一個內存泄漏，這個報告列出了它的泄漏點、長度、分配該內存時的調用堆棧、和泄露內存的內容（分別以16進制和文本格式列出）。

雙擊該堆棧報告的某一行，會自動在代碼編輯器中跳到其所指文件的對應行。這些信息對於我們查找內存泄露將有很大的幫助。

3.3Visual Leak Detector工作原理

在這之前，我們先來看一下Visual C++內置的內存泄漏檢測工具是如何工作的。Visual C++內置的工具CRT Debug Heap工作原來很簡單。在使用Debug版的malloc分配內存時，malloc會在內存塊的頭中記錄分配該內存的文件名及行號。當程序退出時CRT會在main()函數返回之後做一些清理工作，這個時候來檢查調試堆內存，如果仍然有內存沒有被釋放，則一定是存在內存泄漏。從這些沒有被釋放的內存塊的頭中，就可以獲得文件名及行號。

這種靜態的方法可以檢測出內存泄漏及其泄漏點的文件名和行號，但是並不知道泄漏究竟是如何發生的，並不知道該內存分配語句是如何被執行到的。要想了解這些，就必須要對程序的內存分配過程進行動態跟蹤。Visual Leak Detector就是這樣做的。它在每次內存分配時將其上下文記錄下來，當程序退出時，對於檢測到的內存泄漏，查找其記錄下來的上下文信息，並將其轉換成報告輸出。

3.3.1初始化

Visual Leak Detector要記錄每一次的內存分配，而它是如何監視內存分配的呢？Windows提供了分配鉤子(allocation hooks)來監視調試堆內存的分配。它是一個用戶定義的回調函數，在每次從調試堆分配內存之前被調用。在初始化時，Visual Leak Detector使用_CrtSetAllocHook註冊這個鉤子函數，這樣就可以監視從此之後所有的堆內存分配了。

如何保證在Visual Leak Detector初始化之前沒有堆內存分配呢？全局變量是在程序啟動時就初始化的，如果將Visual Leak Detector作為一個全局變量，就可以隨程序一起啟動。但是C/C++並沒有約定全局變量之間的初始化順序，如果其它全局變量的構造函數中有堆內存分配，則可能無法檢測到。Visual Leak Detector使用了C/C++提供的#pragma init_seg來在某種程度上減少其它全局變量在其之前初始化的概率。根據#pragma init_seg的定義，全局變量的初始化分三個階段：首先是compiler段，一般c語言的運行時庫在這個時候初始化；然後是lib段，一般用於第三方的類庫的初始化等；最後是user段，大部分的初始化都在這個階段進行。Visual Leak Detector將其初始化設置在compiler段，從而使得它在絕大多數全局變量和幾乎所有的用戶定義的全局變量之前初始化。

3.3.2記錄內存分配

一個分配鉤子函數需要具有如下的形式：

int YourAllocHook( int allocType, void *userData, size_t size, int blockType, long requestNumber, const unsigned char *filename, int lineNumber);

就像前面說的，它在Visual Leak Detector初始化時被註冊，每次從調試堆分配內存之前被調用。這個函數需要處理的事情是記錄下此時的調用堆棧和此次堆內存分配的唯一標識——requestNumber。

得到當前的堆棧的二進制表示並不是一件很復雜的事情，但是因為不同體系結構、不同編譯器、不同的函數調用約定所產生的堆棧內容略有不同，要解釋堆棧並得到 整個函數調用過程略顯復雜。不過windows提供一個StackWalk64函數，可以獲得堆棧的內容。StackWalk64的聲明如下：

BOOL StackWalk64(
    DWORD MachineType,
    HANDLE hProcess,
    HANDLE hThread,
    LPSTACKFRAME64 StackFrame,
    PVOID ContextRecord,
    PREAD_PROCESS_MEMORY_ROUTINE64 ReadMemoryRoutine,
    PFUNCTION_TABLE_ACCESS_ROUTINE64   FunctionTableAccessRoutine,
    PGET_MODULE_BASE_ROUTINE64 GetModuleBaseRoutine,
    PTRANSLATE_ADDRESS_ROUTINE64 TranslateAddress
);

STACKFRAME64結構表示了堆棧中的一個frame。給出初始的STACKFRAME64，反復調用該函數，便可以得到內存分配點的調用堆棧了。

// Walk the stack.
while (count < _VLD_maxtraceframes) 
{
    count++;
    if (!pStackWalk64(architecture, m_process, m_thread, &frame, &context, NULL, pSymFunctionTableAccess64, pSymGetModuleBase64, NULL)) 
    {
        // Couldn‘t trace back through any more frames.
        break;
    }
    if (frame.AddrFrame.Offset == 0) 
    {
        // End of stack.
        break;
    }

    // Push this frame‘s program counter onto the provided CallStack.
    callstack->push_back((DWORD_PTR)frame.AddrPC.Offset);
}

那麽，如何得到初始的STACKFRAME64結構呢？在STACKFRAME64結構中，其他的信息都比較容易獲得，而當前的程序計數器(EIP)在 x86體系結構中無法通過軟件的方法直接讀取。Visual Leak Detector使用了一種方法來獲得當前的程序計數器。首先，它調用一個函數，則這個函數的返回地址就是當前的程序計數器，而函數的返回地址可以很容易 的從堆棧中拿到。下面是Visual Leak Detector獲得當前程序計數器的程序：

#if defined(_M_IX86) || defined(_M_X64)
#pragma auto_inline(off)
DWORD_PTR VisualLeakDetector::getprogramcounterx86x64 ()
{
    DWORD_PTR programcounter;

    __asm mov AXREG, [BPREG + SIZEOFPTR] // Get the return address out of the current stack frame
    __asm mov [programcounter], AXREG    // Put the return address into the variable we‘ll return

    return programcounter;
}
#pragma auto_inline(on)
#endif // defined(_M_IX86) || defined(_M_X64)

得到了調用堆棧，自然要記錄下來。Visual Leak Detector使用一個類似map的數據結構來記錄該信息。這樣可以方便的從requestNumber查找到其調用堆棧。分配鉤子函數的 allocType參數表示此次堆內存分配的類型，包括_HOOK_ALLOC, _HOOK_REALLOC, 和 _HOOK_FREE，下面代碼是Visual Leak Detector對各種情況的處理。

switch (type) 
{
case _HOOK_ALLOC:
　　visualleakdetector.hookmalloc(request);
　　break;
case _HOOK_FREE:
　　visualleakdetector.hookfree(pdata);
　　break;
case _HOOK_REALLOC:
　　visualleakdetector.hookrealloc(pdata, request);
　　break;
default:
　　visualleakdetector.report("WARNING: Visual Leak Detector: in allochook(): Unhandled allocation type (%d)./n", type);
　　break;
}

這 裏，hookmalloc()函數得到當前堆棧，並將當前堆棧與requestNumber加入到類似map的數據結構中。hookfree()函數從類 似map的數據結構中刪除該信息。hookrealloc()函數依次調用了hookfree()和hookmalloc()。
總之： 鉤子函數在Visual Leak Detector初始化時被註冊，每次從調試堆分配內存之前被調用。這個函數需要處理的事情是記錄下此時的調用堆棧和此次堆內存分配的唯一標識。即鉤子哈思楠記錄並保存內存分配的堆棧情況。

3.3.3檢測內存泄露

前面提到了Visual C++內置的內存泄漏檢測工具的工作原理。與該原理相同，因為全局變量以構造的相反順序析構，在Visual Leak Detector析構時，幾乎所有的其他變量都已經析構，此時如果仍然有未釋放之堆內存，則必為內存泄漏。
分配的堆內存是通過一個鏈表來組織的，檢查內存泄漏則是檢查此鏈表。但是windows沒有提供方法來訪問這個鏈表。Visual Leak Detector使用了一個小技巧來得到它。首先在堆上申請一塊臨時內存，則該內存的地址可以轉換成指向一個_CrtMemBlockHeader結構， 在此結構中就可以獲得這個鏈表。代碼如下：

char *pheap = new char;
_CrtMemBlockHeader *pheader = pHdr(pheap)->pBlockHeaderNext;
delete pheap;

其中pheader則為鏈表首指針。

3.3.4報告生成

前面講了Visual Leak Detector如何檢測、記錄內存泄漏及其其調用堆棧。但是如果要這個信息對程序員有用的話，必須轉換成可讀的形式。Visual Leak Detector使用SymGetLineFromAddr64()及SymFromAddr()生成可讀的報告。

// Iterate through each frame in the call stack.
for (frame = 0; frame < callstack->size(); frame++) 
{
    // Try to get the source file and line number associated with
    // this program counter address.
    if (pSymGetLineFromAddr64(m_process, 
       (*callstack)[frame], &displacement, &sourceinfo)) {
        ...
    }

    // Try to get the name of the function containing this program
    // counter address.
    if (pSymFromAddr(m_process, (*callstack)[frame], 
        &displacement64, pfunctioninfo)) {
        functionname = pfunctioninfo->Name;
    }
    else {
        functionname = "(Function name unavailable)";
    }
    ...
}

概括講來，Visual Leak Detector的工作分為3步，

1）首先在初始化註冊一個鉤子函數；

2）然後在內存分配時該鉤子函數被調用以記錄下當時的現場；

3）最後檢查堆內存分配鏈表以確定是 否存在內存泄漏並將泄漏內存的現場轉換成可讀的形式輸出。
原文鏈接：http://blog.csdn.net/seawen/article/details/3714128

附加linux下內存泄漏檢測工具

Valgrind memcheck

linux調試工具MEMWATC

4.VC++6.0調試：Watch窗口的使用

/*************************************************************************  
*   環境：VC6.0
*   程序功能：使用watch窗口調試程序
*   創建：  2014/3/20
*   版本號：1.0
************************************************************************/
#include <stdio.h>   
#include <windows.h>   
  
class AutoExpand  
{  
public:  
    AutoExpand(int val, char* pval)  
   {  
        a = val;  
        p = pval;  
    }  
private:  
    int a;  
    char *p;  
};  
class CantExpand  
{  
public:  
    CantExpand(int val, char* pval)  
    {  
        a = val;  
        p = pval;  
    }  
private:  
    int a;  
    char *p;  
};  
 
int main(void)  
{  
    int p[4] = {0x31,0x32,0x33,0x34};  
    int *a  = p;  
      
    FILE* fp = fopen("File Not Exist", "r");  
    DWORD dwError = GetLastError();  
      
    AutoExpand ae(10, "abc");  
    CantExpand ce(10, "abc");  
  
    return 0;  
}  

上面代碼中出現的變量先說明一下：

　　p: 是整形數組，含四個元素，總共16Byte；

　　a: 整形指針，指向數組p；

　　fp: 文件指針，用來標識打開的"File Not Exist"，我機器裏是沒這個文件的；

　　dwError: 獲得fopen失敗的錯誤碼。一般來說可以用FormatMessge來格式化這個錯誤原因或者直接用VC自帶的工具errorlookup來查找這個錯誤碼的解釋；

　　ae和ce: 是自定義的AutoExpand類型的變量和CantExpand類型的變量。註意，這兩種類型只有類型名字不同。

　　下面看一下我在調試這個程序的時候，watch窗口的顯示：

View---->debug windows--->watch,call stack,memory,register

上圖中，左邊是Context窗口的Locals頁，顯示所有局部變量。右邊是Watch窗口，是我自己添加的要觀察的對象。　

　　好，先看看整形數組p。我們看到Context窗口的顯示p其實只顯示了數組的地址，點了+號展開後，顯示出了4個整形數據。而右邊窗口，我添加了一個p,c。p後面加個",c"是什麽意思呢？看看效果，p,c下面的[0]，[1]，[2]，[3]顯示的是這4個整形值對應的ascii字符哈。所以從這裏有了第一個小技巧：

　　1.watch窗口中，在整形變量後面加上",c"可以顯示該變量對應的ASCII字符。實際上，可以直接敲數字這麽顯示也行。比如上面右邊窗口中的118,c的對應值是‘v‘。也就是說118對應的ASCII字符是‘v‘。那麽，反過來，要知道一個字符的ASCII碼值怎麽看呢？看上面，‘v‘,d就是顯示字符‘v‘對應的十進制ASCII碼值是118。 ‘v‘，x顯示的是對應的十六進制的ASCII碼值。除了",c" ",d" ",x"外，還有一些其他的參數可以加，見後面的附表。

　　然後我們看看變量a。a是個指針。看左邊窗口，即使點了它的+號展開，也只看到了它指向的地址的第一個元素(49)。如果想要看得更多的數據，也可以像我一樣，在上面的Memory窗口裏看。但是Memory窗口只有一個，要看多個指針指向的數據就麻煩了，切來切去。那就在watch窗口中顯示吧，a,4就可以了，看到我的watch窗口的顯示沒？所以，有了第二個小技巧：

　　2.watch窗口中，把指針當成數組看，只要在指針名後面加上一個長度，就可以想看數組一樣看到對應的數據了。比如我上面的a,4。那麽如果一個指針指向的數據很大，比如一個整形指針a是指向一個1000個整數的大塊內存，我只想看看最後4個數據，要怎樣呢？那就(a+996),4 唄。從第996個數據開始，看4個~

　　接下來這個小技巧是我最喜歡的一個了。調試中遇到系統函數調用失敗的情況，通常都要加上GetLastError()函數獲得返回值，然後查對應的解釋才知道錯誤原因。比如，我上面的代碼要打開一個不存在的文件，結果fopen失敗。取回了錯誤碼dwError=2，一查才知道是文件不存在。那麽可不可以不用查，調試器直接告訴我原因呢？當然可以，不然我寫這幹嘛！剛才的錯誤碼2是記錄在dwError中了，所以只要在watch窗口看看dwError,hr看value欄：系統找不到指定的文件！爽吧！總結一下，第三個小技巧：

　　3. 在watch窗口中察看錯誤原因，只需要在錯誤之後面頰上",hr"就可以了。比如我上面的 dwError,hr 和 2, hr 都能夠顯示錯誤消息。想看某個錯誤碼的解釋，只要後面加上",hr"就輕松搞定，非常方便！這裏還要提一下的是，即使不調用GetLastError()也是可以看錯誤原因的。在fopen()調用完後，直接在watch窗口敲err,hr也可以顯示最近一次的錯誤原因。但是我機器重新裝了os，還沒裝vc，現在用的還是安裝前的屍體。所以這個err,hr的顯示有問題。不過還是有應對之法，那就是強大的TIB信息。watch窗口看看*(unsigned long*)(TIB+0x34), hr也是一樣的。至於為什麽嗎，那就是GetLastError的機制了。

　　還剩2個變量，ae和ce。這兩變量類型名不同，但是其他全都一樣。為什麽這兩個變量在watch窗口中顯示的不一樣呢？ae直接顯示出了類成員的值，ce就顯示了個......嗯，這就是最後一個小技巧：

　　4. 在vc安裝目錄的msdev\bin目錄下有個autoexp.dat文件。可以在裏面自定義數據的顯示。具體的看看它前面的大段說明，說得很詳細。我就是在文件後面加上一行AutoExpand =int_val=<a,d> sz_val=<p,s>。

附表：

　　下表說明調試器可識別的格式說明符。

　　下表包含用於內存位置的格式化符號。

　　可以使用帶有計算為位置的任何值或表達式的內存位置說明符。

C++內存泄漏檢測工具