内存泄露检测.docVIP

用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应用。thrift#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，输出结果和上面差不 多，不过显示了更多未释放的内存。