用Valgrind查找內存泄漏和無效內存訪問
Valgrind是x86架構Linux上的多重用途代碼剖析和內存調試工具。你可以在它的環境中運行你的程序來監視內存的使用情況，比如C語言中的malloc和free或者C++中的new和delete。如果你使用了未初始化內存，在數組末端外設置內存或是忘記釋放指針，Valgrind都可以檢測出來。儘管Valgrind還可以做其它的工作，本教程仍然集中在如何使用它來發現內存相關錯誤，因爲這也程序員經常出現的錯誤。
Windows用戶不必沮喪，雖然在Windows上沒有Valgrind可用，但是你可以試一試IBM的Purify，它在功能上和Valgrind相似。
獲得Valgrind
如果你正使用Linux但卻沒有安裝Valgrind，可以去http://valgrind.org/免費下載一份。
安裝過程非常簡單，只需要用bzip2解壓縮下載的軟件包並將其展開即可(下面例子中的XYZ是版本號)。
bzip2 -d valgrind-XYZ.tar.bz2
tar -xf valgrind-XYZ.tar
或者用更簡單的方法:
tar jxf valgrind-XYZ.tar.bz2
這會創建一個叫valgrind-XYZ的目錄，進入該目錄並運行
./configure
make
make install
好了，現在你已經安裝了Valgrind，可以開始瞭解如何用它了。
工具：
MemcheckMemcheck檢查內存管理問題，主要用於C和C++程序。當一個程序在Memcheck監督下運行時，所有的內存讀寫都被檢查，對malloc/new/free/delete的調用都被截取。所以，Memcheck可以檢查程序的下列問題：
訪問它不應該訪問的內存（沒有被分配的區域，已經被釋放的區域，超過堆尾部的區域，棧中不可訪問的區域）。
以危險的方式使用未初始化的值。
內存泄漏。
堆的錯誤釋放（釋放兩次，不匹配的釋放）。
給memcpy()和相關函數傳遞重疊的源和目的內存塊。
一旦發現這些錯誤，Memcheck就會報告，給出錯誤所在的源代碼行號，到達該行的函數調用的棧回溯。Memcheck跟蹤字節級的尋址，位級的值初始化。因此，它可以檢測單獨的未初始化位的使用，不會報告位域操作中的假的錯誤信息。運行在Memcheck上的程序會減慢10－30倍。
Cachegrind
Cachegrind是一個cache profiler。它執行你的CPU中的l1，D1和L2 cache的詳細模擬，因此能精確的查明在你的代碼中cache未命中的來源。它確定cache未命中的數量，每個函數，每個模塊和整個程序的每行源代碼的內存引用和指令執行的摘要。它可以用於任何語言寫的程序。在Cachegrind上運行的程序會減慢20－100倍。
Callgrind
由Josef Weidendorfer做的Callgrind是Cachegrind的擴展。提供Cachegrind提供的所有信息，還有關於調用圖的額外信息。它被打包進Valgrind3.2.0的發佈版。
Massif
Massif是一個堆profiler。它通過取得程序的常規的堆映象，來做詳細的堆壓型（profiling）。隨着時間的推移，它產生一個圖形顯示堆的使用情況，包括程序負責的大多數內存分配的信息。圖形被文本或HTML文件補充，包括大多數內存被分配在哪裏的信息。在Massif上運行的程序會減慢20倍。
Helgrind
Helgrind是一個在多線程程序中找到數據競爭的線程調試器。它尋找被多於一個（POSIX p-）線程訪問的內存分配，要不就是那種那被找到的不是被一直使用的（pthread_mutex_）鎖。這樣的地方是線程間不正確的同步的預示，可能引起很難找到的時序依賴的問題。它對使用pthread的任何程序都有用。它是帶有一點實驗性質的工具。
Lackey，Nulgrind
Lackey和Nulgrind也包含在Valgrind的發行版中。做的還不是很完善，主要用於測試和說明的目的。
用Valgrind查找內存泄漏
內存泄漏是最難發現的常見錯誤之一，因爲除非用完內存或調用malloc失敗，否則都不會導致任何問題。實際上，使用像C或C++這類沒有垃圾回收機制的語言時，你一大半的時間都花費在處理如何正確釋放內存上。如果程序運行時間足夠長，一個小小的失誤也會對程序造成重大的影響。
Valgrind支持很多工具:Memcheck，Addrcheck，Cachegrind，Massif，Helgrind和Callgrind等。在運行Valgrind時，你必須指明想用的工具。在這篇教程中，我們主要集中在內存檢查工具上，它可以幫助我們檢查內存使用情況(呵呵，其它工具我也不會用)。如果沒有其它參數，Valgrind在程序結束後給出關於free和malloc總共調用次數的簡報:(注意，18490是進程號，你的機器上可能是其它值)
% valgrind --tool=memcheck program_name
...
=18515== malloc/free: in use at exit: 0 bytes in 0 blocks.
==18515== malloc/free: 1 allocs, 1 frees, 10 bytes allocated.
==18515== For a detailed leak analysis, rerun with: --leak-check=yes
如果程序中有內存泄漏的現象，內存分配的數量和內存釋放的數量會不一致(你不能使用一個free調用來釋放多個分配的內存)。
如果程序內存分配和釋放的數量不一致，你可以加上leak-check參數重新運行程序，這樣就可以看見分配了內存但卻沒有釋放的代碼。
爲了演示這個功能，我寫了一個簡單的C程序並編譯生成"example1"應用。
#include
int main()
{
char *x = malloc(100); /* or, in C++, "char *x = new char[100] */
return 0;
}
% valgrind --tool=memcheck --leak-check=yes example1
在運行結果中，給出了調用malloc卻沒有調用free的函數列表。
==2116== 100 bytes in 1 blocks are definitely lost in loss record 1 of 1
==2116== at 0x1B900DD0: malloc (vg_replace_malloc.c:131)
==2116== by 0x804840F: main (in /home/cprogram/example1)
上面的結果並沒有告訴我們更多需要的信息，我們只知道在main函數中的malloc調用導致了內存泄漏，但並不知道是程序中的哪一行調用了malloc。這是因爲我們在編譯程序時，沒有給gcc加上-g參數，相關的調試信息就丟失了。重編一次再運行，我們就得到了更多的信息(片斷)。
==2330== 100 bytes in 1 blocks are definitely lost in loss record 1 of 1
==2330== at 0x1B900DD0: malloc (vg_replace_malloc.c:131)
==2330== by 0x804840F: main (example1.c:5)
現在我們已經確切知道導致內存泄漏的是哪一行代碼了。儘管知道在哪裏釋放內存仍然是一個問題，至少我們已經知道該從哪裏入手。因爲對每一次需要動態分配的內存，你都有一個何時分配，何時釋放的使用計劃，既然已經知道導致內存泄漏的分配點，也就基本理清了內存的使用計劃，有助於定位正確釋放內存的位置。
在加上--leak-check=yes參數後不再顯示內存泄漏錯誤前，你可能需要重複修改代碼很多次，一個優秀的，沒有內存泄漏的軟件就是這樣誕生的:-)。在運行Valgrind時加上--show-reachable=yes參數，可以找到每一個未來匹配的free或new，輸出結果和上面差不多，不過顯示了更多未釋放的內存。
用Valgrind查找無效指針使用
用memcheck工具，Valgrind也可以找出無效堆內存使用。比如，如果你用malloc或new分配了一個數組，並訪問數組末端後面的內存:
char *x = malloc(10);
x[10] = ´a´;
Valgrind可以檢測出這個錯誤。用Valgrind運行下面的示例程序:example2
#include
int main()
{
char *x = malloc(10);
x[10] = ´a´;
return 0;
}
%valgrind --tool=memcheck --leak-check=yes example2
其結果是(片斷)
==9814== Invalid write of size 1
==9814== at 0x804841E: main (tst.c:6)
==9814== Address 0x1BA3607A is 0 bytes after a block of size 10 alloc´d
==9814== at 0x1B900DD0: malloc (vg_replace_malloc.c:131)
==9814== by 0x804840F: main (example2.c:5)
這個信息表明我們分配了10字節的內存，但是訪問了超出範圍的內存，因此，我們就進行了一個´非法寫´操作。如果試圖從那塊內存讀取數據，我們就會得到´Invalid read of size X´的警告(X是試圖讀取數據的大小，char是一個字節，而int根據系統的不同可能是2個字節或4個字節)。通常，Valgrind顯示出函數調用棧信息以方便我們準確定位錯誤。
檢測使用未初始化變量
還有一類Valgrind可以檢測的操作是在條件判斷語句中使用未初始化變量。也許你應該養成在聲明變量時就進行初始化的習慣，不過Valgrind仍然可以幫助你找出使用未初始化變量的地方。比如，運行下面代碼生成的示例程序，example3
#include
int main()
{
int x;
if(x == 0)
{
printf("X is zero"); /* replace with cout and include
iostream for C++ */
}
return 0;
}
Valgrind會給出下面的結果(片斷)
==17943== Conditional jump or move depends on uninitialised value(s)
==17943== at 0x804840A: main (example3.c:6)
Valgrind甚至可以知道如果一個變量被賦予一個未初始化的變量，這個變量仍然處於"未初始化"狀態。比如運行下列代碼:
#include
int foo(int x)
{
if(x < 10)
{
printf("x is less than 10\n");
}
}
int main()
{
int y;
foo(y);
}
Valgrind會給出下列警告:
==4827== Conditional jump or move depends on uninitialised value(s)
==4827== at 0x8048366: foo (example4.c:5)
==4827== by 0x8048394: main (example4.c:14)
你可能以爲錯誤在foo中，和調用棧上的其它函數沒有關係。但是因爲main函數傳遞了一個未初始化值給foo，我們可以根據調用棧信息順藤摸瓜，找到真正沒有初始化變量的代碼。
Valgrind僅僅有助於你在能夠運行到代碼中檢測這些錯誤，請確信在測試中覆蓋代碼的每一個分支。
Valgrind還能發現什麼?
Valgrind還能發現其它不正確使用內存的錯誤:如果你對同一塊內存釋放了兩次，Valgrind就會探測到，而你則得到非法free的調用棧信息。
Valgrind也能檢測到使用不正確方法釋放內存的錯誤。比如，在C++語言中有三種基本的內存釋放方法:free，delete和delete[]。free函數應該僅與malloc函數相對應--在一些系統上，你可能無須面對這個問題，但這樣不具備可移植性。delete[]應該又只能和new[](分配數組)相對應。(也許有些編譯器允許你不去理會這些規則，但不能保證所有的編譯器都允許你這樣做，畢竟它不是標準的一部分。)
如果程序中存在這些問題，你會得到下列錯誤信息:
Mismatched free() / delete / delete []
這些錯誤都應該被立刻修復，即使你的程序偶然能夠正常運行。
Valgrind不能查出哪些錯誤?
Valgrind不對靜態數組(分配在棧上)進行邊界檢查。如果在程序中聲明瞭一個數組:
int main()
{
char x[10];
x[11] = ´a´;
}
Valgrind則不會警告你!出於測試目的，你可以把數組改爲動態在堆上分配的數組，這樣就可能進行邊界檢查了。這個方法好像有點得不償失的感覺。
更多告誡
使用Valgrind的負面影響是什麼?它佔用了更多的內存--可達兩倍於你程序的正常使用量。如果你用Valgrind來檢測使用大量內存的程序就會遇到問題，它可能會用很長的時間來運行測試。大多數情況下，這都不是問題，即使速度慢也僅是檢測時速度慢，如果你用Valgrind來檢測一個正常運行時速度就很慢的程序，這下問題就大了。
Valgrind不可能檢測出你在程序中犯下的所有錯誤--如果你不檢查緩衝區溢出，Valgrind也不會告訴你代碼寫了它不應該寫的內存。
總結
Valgrind是x86架構上的工具，只能在Linux上運行(FreeBSD和NetBSD上的相關版本正在開發中)。它允許程序員在它的環境裏測試程序以檢測未配對malloc調用錯誤和其它使用非法內存(未初始化內存)的錯誤以及非法內存操作(比如同一塊內存釋放兩次或調用不正確的析構函數)。Valgrind不檢查靜態分配數組的使用情況。