用Valgrind查找内存泄漏和无效内存访问
Valgrind是x86架构Linux上的多重用途代码剖析和内存调试工具。你可以在它的环境中运行你的程序来监视内存的使用情况，比如C语言中的malloc和free或者C++中的new和delete。如果你使用了未初始化内存，在数组末端外设置内存或是忘记释放指针，Valgrind都可以检测出来。尽管Valgrind还可以做其它的工作，本教程仍然集中在如何使用它来发现内存相关错误，因为这也程序员经常出现的错误。
Windows用户不必沮丧，虽然在Windows上没有Valgrind可用，但是你可以试一试IBM的，它在功能上和Valgrind相似。
安装过程非常简单，只需要用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，可以开始了解如何用它了。
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，输出结果和上面差不多，不过显示了更多未释放的内存。
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显示出函数调用栈信息以方便我们准确定位错误。
#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也能检测到使用不正确方法释放内存的错误。比如，在C++语言中有三种基本的内存释放方法:free，delete和delete[]。free函数应该仅与malloc函数相对应--在一些系统上，你可能无须面对这个问题，但这样不具备可移植性。delete[]应该又只能和new[](分配数组)相对应。(也许有些编译器允许你不去理会这些规则，但不能保证所有的编译器都允许你这样做，毕竟它不是标准的一部分。)
如果程序中存在这些问题，你会得到下列错误信息:
Mismatched free() / delete / delete []
这些错误都应该被立刻修复，即使你的程序偶然能够正常运行。
int main()
{
char x[10];
x[11] = ´a´;
}
Valgrind则不会警告你!出于测试目的，你可以把数组改为动态在堆上分配的数组，这样就可能进行边界检查了。这个方法好像有点得不偿失的感觉。
Valgrind不可能检测出你在程序中犯下的所有错误--如果你不检查缓冲区溢出，Valgrind也不会告诉你代码写了它不应该写的内存。
Windows用户不必沮丧，虽然在Windows上没有Valgrind可用，但是你可以试一试IBM的，它在功能上和Valgrind相似。
获得Valgrind
如果你正使用Linux但却没有安装Valgrind，可以去免费下载一份。安装过程非常简单，只需要用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，可以开始了解如何用它了。
用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也不会告诉你代码写了它不应该写的内存。