Valgrind检查内存泄露简介.docx

内存动态分析工具Valgrind初探 用C/C+开发其中最令人头疼的一个问题就是内存管理，有时候为了查找一个内存泄漏或者一个内存访问越界，需要要花上好几天时间，如果有一款工具能够帮助我们做这件事情就好了，valgrind正好就是这样的一款工具。Valgrind是一款基于模拟linux下的程序调试器和剖析器的软件套件，可以运行于x86, amd64和ppc32架构上。valgrind包含一个核心，它提供一个虚拟的CPU运行程序，还有一系列的工具，它们完成调试，剖析和一些类似的任务。valgrind是高度模块化的，所以开发人员或者用户可以给它添加新的工具而不会损坏己有的结构。你可以在它的网站上下载到最新的valgrind，它是开放源码和免费的。3.7.0版本的下载地址为/downloads/valgrind-3.7.0.tar.bz2。valgrind包含几个标准的工具，它们是：1、memcheckmemcheck探测程序中内存管理存在的问题。它检查所有对内存的读/写操作，并截取所有的malloc/new/free/delete调用。因此memcheck工具能够探测到以下问题：1）使用未初始化的内存2）读/写已经被释放的内存3）读/写内存越界4）读/写不恰当的内存栈空间5）内存泄漏6）使用malloc/new/new和free/delete/delete不匹配。2、cachegrindcachegrind是一个cache剖析器。它模拟执行CPU中的L1, D1和L2 cache，因此它能很精确的指出代码中的cache未命中。如果你需要，它可以打印出cache未命中的次数，内存引用和发生cache未命中的每一行代码，每一个函数，每一个模块和整个程序的摘要。如果你要求更细致的信息，它可以打印出每一行机器码的未命中次数。在x86和amd64上，cachegrind通过CPUID自动探测机器的cache配置，所以在多数情况下它不再需要更多的配置信息了。3、helgrindhelgrind查找多线程程序中的竞争数据。helgrind查找内存地址，那些被多于一条线程访问的内存地址，但是没有使用一致的锁就会被查出。这表示这些地址在多线程间访问的时候没有进行同步，很可能会引起很难查找的时序问题。valgrind被设计成非侵入式的，它直接工作于可执行文件上，因此在检查前不需要重新编译、连接和修改你的程序。要检查一个程序很简单，只需要执行下面的命令就可以了 valgrind -tool=tool_name program_name 比如我们要对ls -l命令做内存检查，只需要执行下面的命令就可以了 valgrind -tool=memcheck ls -l 不管是使用哪个工具，valgrind在开始之前总会先取得对你的程序的控制权，从可执行关联库里读取调试信息。然后在valgrind核心提供的虚拟CPU上运行程序，valgrind会根据选择的工具来处理代码，该工具会向代码中加入检测代码，并把这些代码作为最终代码返回给valgrind核心，最后valgrind核心运行这些代码。 如果要检查内存泄漏，只需要增加-leak-check=yes就可以了，命令如下 valgrind -tool=memcheck -leak-check=yes ls -l 不同工具间加入的代码变化非常的大。在每个作用域的末尾，memcheck加入代码检查每一片内存的访问和进行值计算，代码大小至少增加12倍，运行速度要比平时慢25到50倍。 valgrind模拟程序中的每一条指令执行，因此，检查工具和剖析工具不仅仅是对你的应用程序，还有对共享库，GNU C库，X的客户端库都起作用。首先，在编译程序的时候打开调试模式（gcc编译器的-g选项）。如果没有调试信息，即使最好的valgrind工具也将中能够猜测特定的代码是属于哪一个函数。打开调试选项进行编译后再用valgrind检查，valgrind将会给你的个详细的报告，比如哪一行代码出现了内存泄漏。当检查的是C+程序的时候，还应该考虑另一个选项 -fno-inline。它使得函数调用链很清晰，这样可以减少你在浏览大型C+程序时的混乱。比如在使用这个选项的时候，用memcheck检查openoffice就很容易。当然，你可能不会做这项工作，但是使用这一选项使得valgrind生成更精确的错误报告和减少混乱。一些编译优化选项(比如-O2或者更高的优化选项)，可能会使得memcheck提交错误的未初始化报告，因此，为了使得valgrind的报告更精确，在编译的时候最好不要使用优化选项。如果程序是通过脚本启动的，可以修改脚本里启动程序的代码，或者使用-trace-children=yes选项来运行脚本。今天，对它做一下初步的测试，测试平台Ubuntu 10.04 64bit。下载完成后，解压源码，执行./configure;make;make install后，默认安装到/usr/local/bin下，执行： valgrind ls -l 提示：=14336= Memcheck, a memory error detector =14336= Copyright (C) 2002-2011, and GNU GPLd, by Julian Seward et al. =14336= Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info =14336= Command: ls -l =14336= valgrind: Fatal error at startup: a function redirection valgrind: which is mandatory for this platform-tool combination valgrind: cannot be set up. Details of the redirection are: valgrind: valgrind: A must-be-redirected function valgrind: whose name matches the pattern: strlen valgrind: in an object with soname matching: ld-linux-x86-64.so.2 valgrind: was not found whilst processing valgrind: symbols from the object with soname: ld-linux-x86-64.so.2 valgrind: valgrind: Possible fixes: (1, short term): install glibcs debuginfo valgrind: package on this machine. (2, longer term): ask the packagers valgrind: for your Linux distribution to please in future ship a non- valgrind: stripped ld.so (or whatever the dynamic linker .so is called) valgrind: that exports the above-named function using the standard valgrind: calling conventions for this platform. The package you need valgrind: to install for fix (1) is called valgrind: valgrind: On Debian, Ubuntu: libc6-dbg valgrind: On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo valgrind: valgrind: Cannot continue - exiting now. Sorry. 大概是说我的glibc是个strip后的版本，需要下载debug版，debug版的名字是libc6-dbg。执行：sudo apt-get install libc6-dbg 再次执行valgrind ls -l，输出：=14378= Memcheck, a memory error detector=14378= Copyright (C) 2002-2011, and GNU GPLd, by Julian Seward et al.=14378= Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info=14378= Command: ls -l=14378=total 108drwxr-xr-x 2 root root 4096 2012-07-13 03:26 bindrwxr-xr-x 3 root root 4096 2012-07-13 07:36 bootdrwxr-xr-x 2 root root 4096 2012-07-13 07:06 cdromdrwxr-xr-x 17 root root 3620 2012-07-24 03:00 devdrwxr-xr-x 128 root root 12288 2012-07-24 03:06 etcdrwxr-xr-x 3 root root 4096 2012-07-13 08:16 homelrwxrwxrwx 1 root root 33 2012-07-13 07:07 initrd.img - boot/initrd.img-2.6.32-38-genericdrwxr-xr-x 16 root root 12288 2012-07-13 03:23 libdrwxr-xr-x 2 root root 4096 2012-07-13 03:24 lib32lrwxrwxrwx 1 root root 4 2012-07-13 07:03 lib64 - /libdrwx- 2 root root 16384 2012-07-13 07:03 lost+founddrwxr-xr-x 4 root root 4096 2012-07-13 02:13 mediadrwxr-xr-x 2 root root 4096 2012-02-03 04:21 mntdrwxr-xr-x 2 root root 4096 2012-07-13 07:03 optdr-xr-xr-x 182 root root 0 2012-07-24 02:58 procdrwx- 8 root root 4096 2012-07-24 21:25 rootdrwxr-xr-x 2 root root 4096 2012-07-16 01:21 sbindrwxr-xr-x 2 root root 4096 2009-12-05 17:25 selinuxdrwxr-xr-x 2 root root 4096 2012-07-13 07:03 srvdrwxr-xr-x 13 root root 0 2012-07-24 02:58 sysdrwxrwxrwx 2 root root 4096 2012-07-16 01:39 tftpbootdrwxrwxrwt 14 root root 4096 2012-07-24 21:31 tmpdrwxr-xr-x 11 root root 4096 2012-07-13 03:23 usrdrwxr-xr-x 15 root root 4096 2012-07-13 07:31 varlrwxrwxrwx 1 root root 30 2012-07-13 07:07 vmlinuz - boot/vmlinuz-2.6.32-38-genericdrwxrwxrwx 6 root root 4096 2012-07-24 03:02 work=14378=14378= HEAP SUMMARY:=14378= in use at exit: 20,081 bytes in 58 blocks=14378= total heap usage: 1,798 allocs, 1,740 frees, 164,568 bytes allocated=14378=14378= LEAK SUMMARY:=14378= definitely lost: 240 bytes in 3 blocks=14378= indirectly lost: 480 bytes in 20 blocks=14378= possibly lost: 0 bytes in 0 blocks=14378= still reachable: 19,361 bytes in 35 blocks=14378= suppressed: 0 bytes in 0 blocks=14378= Rerun with -leak-check=full to see details of leaked memory=14378=14378= For counts of detected and suppressed errors, rerun with: -v=14378= ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)看来ls这个命令是没有任何内存问题的。这里的“14378”指的是执行ls -l的进程ID，这有利于区别不同进程的报告。memcheck会给出报告，分配置和释放了多少内存，有多少内存泄漏了，还有多少内存的访问是可达的，检查了多少字节的内存。好了，我们自己写一段吧：#include void bug ( )int a100, * b, * c;b=new int100;/memset(a, 0, 2000);a100=0;b100=0;*c=0;/* - end of function bug - */int main ( int argc, char *argv )bug();return 0;/* - end of function main - */这段代码囊括了经常遇到的内存问题：泄漏、野指针和越界访问。那么用valgrind测试的结果如何呢？（编译时请加上-ggdb -O0，以便valgrind能够定位到具体出问题的位置）=14525= Memcheck, a memory error detector=14525= Copyright (C) 2002-2011, and GNU GPLd, by Julian Seward et al.=14525= Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info=14525= Command: ./membug=14525=14525= Invalid write of size 4=14525= at 0x40064E: bug() (membug.cpp:14)=14525= by 0x400673: main (membug.cpp:25)=14525= Address 0x59601d0 is 0 bytes after a block of size 400 allocd=14525= at 0x4C28112: operator new(unsigned long) (vg_replace_malloc.c:348)=14525= by 0x400638: bug() (membug.cpp:11)=14525= by 0x400673: main (membug.cpp:25)=14525=14525= Use of uninitialised value of size 8=14525= at 0x400658: bug() (membug.cpp:15)=14525= by 0x400673: main (membug.cpp:25)=14525=14525= Invalid write of size 4=14525= at 0x400658: bug() (membug.cpp:15)=14525= by 0x400673: main (membug.cpp:25)=14525= Address 0x0 is not stackd, mallocd or (recently) freed=14525=14525=14525= Process terminating with default action of signal 11 (SIGSEGV)=14525= Access not within mapped region at address 0x0=14525= at 0x400658: bug() (membug.cpp:15)=14525= by 0x400673: main (membug.cpp:25)=14525= If you believe this happened as a result of a stack=14525= overflow in your programs main thread (unlikely but=14525= possible), you can try to increase the size of the=14525= main thread stack using the -main-stacksize= flag.=14525= The main thread stack size used in this run was 8388608.=14525=14525= HEAP SUMMARY:=14525= in use at exit: 400 bytes in 1 blocks=14525= total heap usage: 1 allocs, 0 frees, 400 bytes allocated=14525=14525= 400 bytes in 1 blocks are still reachable in loss record 1 of 1=14525= at 0x4C28112: operator new(unsigned long) (vg_replace_malloc.c:348)=14525= by 0x400638: bug() (membug.cpp:11)=14525= by 0x400673: main (membug.cpp:25)=14525=14525= LEAK SUMMARY:=14525= definitely lost: 0 bytes in 0 blocks=