valgrind介绍

一  valgrind是什么？

Valgrind是一套Linux下，开放源代码（GPL V2）的仿真调试工具的集合。Valgrind由内核（core）以及基于内核的其他调试工具组成。内核类似于一个框架（framework），它模拟了一个CPU环境，并提供服务给其他工具；而其他工具则类似于插件 (plug-in)，利用内核提供的服务完成各种特定的内存调试任务。Valgrind的体系结构如下图所示：

valgrind的结构图

Valgrind包括如下一些工具：

Memcheck。这是valgrind应用最广泛的工具，一个重量级的内存检查器，能够发现开发中绝大多数内存错误使用情况，比如：使用未初始化的内存，使用已经释放了的内存，内存访问越界等。这也是本文将重点介绍的部分。Callgrind。它主要用来检查程序中函数调用过程中出现的问题。Cachegrind。它主要用来检查程序中缓存使用出现的问题。Helgrind。它主要用来检查多线程程序中出现的竞争问题。Massif。它主要用来检查程序中堆栈使用中出现的问题。Extension。可以利用core提供的功能，自己编写特定的内存调试工具

linux下内存空间布置：

一个典型的Linux C程序内存空间由如下几部分组成：

代码段（.text）。这里存放的是CPU要执行的指令。代码段是可共享的，相同的代码在内存中只会有一个拷贝，同时这个段是只读的，防止程序由于错误而修改自身的指令。初始化数据段（.data）。这里存放的是程序中需要明确赋初始值的变量，例如位于所有函数之外的全局变量：int val="100"。需要强调的是，以上两段都是位于程序的可执行文件中，内核在调用exec函数启动该程序时从源程序文件中读入。未初始化数据段（.bss）。位于这一段中的数据，内核在执行该程序前，将其初始化为0或者null。例如出现在任何函数之外的全局变量：int sum;堆（Heap）。这个段用于在程序中进行动态内存申请，例如经常用到的malloc，new系列函数就是从这个段中申请内存。栈（Stack）。函数中的局部变量以及在函数调用过程中产生的临时变量都保存在此段中。

Memcheck 能够检测出内存问题，关键在于其建立了两个全局表。

Valid-Value 表：

对于进程的整个地址空间中的每一个字节(byte)，都有与之对应的 8 个 bits；对于 CPU 的每个寄存器，也有一个与之对应的 bit 向量。这些 bits 负责记录该字节或者寄存器值是否具有有效的、已初始化的值。

Valid-Address 表

对于进程整个地址空间中的每一个字节(byte)，还有与之对应的 1 个 bit，负责记录该地址是否能够被读写。

检测原理：

当要读写内存中某个字节时，首先检查这个字节对应的 A bit。如果该A bit显示该位置是无效位置，memcheck 则报告读写错误。内核（core）类似于一个虚拟的 CPU 环境，这样当内存中的某个字节被加载到真实的 CPU 中时，该字节对应的 V bit 也被加载到虚拟的 CPU 环境中。一旦寄存器中的值，被用来产生内存地址，或者该值能够影响程序输出，则 memcheck 会检查对应的V bits，如果该值尚未初始化，则会报告使用未初始化内存错误。

Valgrind 使用

用法: valgrind [options] prog-and-args [options]: 常用选项，适用于所有Valgrind工具

-tool=<name> 最常用的选项。运行 valgrind中名为toolname的工具。默认memcheck。 h –help 显示帮助信息。 -version 显示valgrind内核的版本，每个工具都有各自的版本。 q –quiet 安静地运行，只打印错误信息。 v –verbose 更详细的信息, 增加错误数统计。 -trace-children=no|yes 跟踪子线程? [no] -track-fds=no|yes 跟踪打开的文件描述？[no] -time-stamp=no|yes 增加时间戳到LOG信息? [no] -log-fd=<number> 输出LOG到描述符文件 [2=stderr] -log-file=<file> 将输出的信息写入到filename.PID的文件里，PID是运行程序的进行ID -log-file-exactly=<file> 输出LOG信息到 file -log-file-qualifier=<VAR> 取得环境变量的值来做为输出信息的文件名。 [none] -log-socket=ipaddr:port 输出LOG到socket ，ipaddr:port

LOG信息输出

-xml=yes 将信息以xml格式输出，只有memcheck可用 -num-callers=<number> show <number> callers in stack traces [12] -error-limit=no|yes 如果太多错误，则停止显示新错误? [yes] -error-exitcode=<number> 如果发现错误则返回错误代码 [0=disable] -db-attach=no|yes 当出现错误，valgrind会自动启动调试器gdb。[no] -db-command=<command> 启动调试器的命令行选项[gdb -nw %f %p]

适用于Memcheck工具的相关选项：

-leak-check=no|summary|full 要求对leak给出详细信息? [summary] -leak-resolution=low|med|high how much bt merging in leak check [low] -show-reachable=no|yes show reachable blocks in leak check? [no]

valgrind 命令行解释：

可使用的工具如下：         o cachegrind是一个缓冲模拟器。它可以用来标出你的程序每一行执行的指令            数和导致的缓冲不命中数。         o callgrind在cachegrind基础上添加调用追踪。它可以用来得到调用的次数            以及每次函数调用的开销。作为对cachegrind的补充，callgrind可以分别            标注各个线程，以及程序反汇编输出的每条指令的执行次数以及缓存未命中            数。         o helgrind能够发现程序中潜在的条件竞争。         o lackey是一个示例程序，以其为模版可以创建你自己的工具。在程序结束后，         它打印出一些基本的关于程序执行统计数据。         o massif是一个堆剖析器，它测量你的程序使用了多少堆内存。         o memcheck是一个细粒度的的内存检查器。         o none没有任何功能。它它一般用于Valgrind的调试和基准测试。  基本选项：         这些选项对所有工具都有效。         -h --help                显示所有选项的帮助，包括内核和选定的工具两者。         --help-debug                和--help相同，并且还能显示通常只有Valgrind的开发人员使用的调试                选项。         --version                显示Valgrind内核的版本号。工具可以有他们自已的版本号。这是一种                保证工具只在它们可以运行的内核上工作的一种设置。这样可以减少在                工具和内核之间版本兼容性导致奇怪问题的概率。         -q --quiet                安静的运行，只打印错误信息。在进行回归测试或者有其它的自动化测                试机制时会非常有用。         -v --verbose                显示详细信息。在各个方面显示你的程序的额外信息，例如：共享对象                加载，使用的重置，执行引擎和工具的进程，异常行为的警告信息。重                复这个标记可以增加详细的级别。         -d     调试Valgrind自身发出的信息。通常只有Valgrind开发人员对此感兴趣。                重复这个标记可以产生更详细的输出。如果你希望发送一个bug报告，通                过-v -v -d -d生成的输出会使你的报告更加有效。         --tool=<toolname> [default: memcheck]                运行toolname指定的Valgrind，例如，Memcheck, Addrcheck, Cachegrind,                等等。         --trace-children=<yes|no> [default: no]                当这个选项打开时，Valgrind会跟踪到子进程中。这经常会导致困惑，而                且通常不是你所期望的，所以默认这个选项是关闭的。         --track-fds=<yes|no> [default: no]                当这个选项打开时，Valgrind会在退出时打印一个打开文件描述符的列表。                每个文件描述符都会打印出一个文件是在哪里打开的栈回溯，和任何与此                文件描述符相关的详细信息比如文件名或socket信息。         --time-stamp=<yes|no> [default: no]                当这个选项打开时，每条信息之前都有一个从程序开始消逝的时间，用天，                小时，分钟，秒和毫秒表示。         --log-fd=<number> [default: 2, stderr]                指定Valgrind把它所有的消息都输出到一个指定的文件描述符中去。默认值                2,　是标准错误输出(stderr)。注意这可能会干扰到客户端自身对stderr                的使用, Valgrind的输出与客户程序的输出将穿插在一起输出到stderr。         --log-file=<filename>                指定Valgrind把它所有的信息输出到指定的文件中。实际上，被创建文件的                文件名是由filename、'.'和进程号连接起来的（即<filename>.<pid>），                从而每个进程创建不同的文件。         --log-file-exactly=<filename>                类似于--log-file，但是后缀".pid"不会被添加。如果设置了这个选项，                使用Valgrind跟踪多个进程，可能会得到一个乱七八糟的文件。                     --log-file-qualifier=<VAR>                当和--log-file一起使用时，日志文件名将通过环境变量$VAR来筛选。这                对于MPI程序是有益的。更多的细节，查看手册2.3节 "注解"。         --log-socket=<ip-address:port-number>                指定Valgrind输出所有的消息到指定的IP，指定的端口。当使用1500端口                时，端口有可能被忽略。如果不能建立一个到指定端口的连接，Valgrind                将输出写到标准错误(stderr)。这个选项经常和一个Valgrind监听程序一                起使用。更多的细节，查看手册2.3节 "注解"。  错误相关选项：         这些选项适用于所有产生错误的工具，比如Memcheck,　但是Cachegrind不行。         --xml=<yes|no> [default: no]                当这个选项打开时，输出将是XML格式。这是为了使用Valgrind的输出做为                输入的工具，例如GUI前端更加容易些。目前这个选项只在Memcheck时生效。         --xml-user-comment=<string>                在XML开头 附加用户注释，仅在指定了--xml=yes时生效，否则忽略。         --demangle=<yes|no> [default: yes]                打开/关闭C++的名字自动解码。默认打开。当打开时，Valgrind将尝试着把                编码过的C++名字自动转回初始状态。这个解码器可以处理g++版本为2.X,                3.X或4.X生成的符号。                一个关于名字编码解码重要的事实是，禁止文件中的解码函数名仍然使用                他们未解码的形式。Valgrind在搜寻可用的禁止条目时不对函数名解码，                因为这将使禁止文件内容依赖于Valgrind的名字解码机制状态， 会使速度                变慢，且无意义。         --num-callers=<number> [default: 12]                默认情况下，Valgrind显示12层函数调用的函数名有助于确定程序的位置。                可以通过这个选项来改变这个数字。这样有助在嵌套调用的层次很深时确定                程序的位置。注意错误信息通常只回溯到最顶上的4个函数。(当前函数，和                它的3个调用者的位置)。所以这并不影响报告的错误总数。                这个值的最大值是50。注意高的设置会使Valgrind运行得慢，并且使用更多                的内存,但是在嵌套调用层次比较高的程序中非常实用。         --error-limit=<yes|no> [default: yes]                当这个选项打开时，在总量达到10,000,000，或者1,000个不同的错误，                Valgrind停止报告错误。这是为了避免错误跟踪机制在错误很多的程序                下变成一个巨大的性能负担。         --error-exitcode=<number> [default: 0]                指定如果Valgrind在运行过程中报告任何错误时的退出返回值，有两种情                况；当设置为默认值(零)时，Valgrind返回的值将是它模拟运行的程序的                返回值。当设置为非零值时，如果Valgrind发现任何错误时则返回这个值。                在Valgrind做为一个测试工具套件的部分使用时这将非常有用，因为使测                试工具套件只检查Valgrind返回值就可以知道哪些测试用例Valgrind报告                了错误。         --show-below-main=<yes|no> [default: no]                默认地，错误时的栈回溯不显示main()之下的任何函数(或者类似的函数像                glibc的__libc_start_main()，如果main()没有出现在栈回溯中)；这些大                部分都是令人厌倦的C库函数。如果打开这个选项，在main()之下的函数也                将会显示。         --suppressions=<filename> [default: $PREFIX/lib/valgrind/default.supp]                指定一个额外的文件读取不需要理会的错误；你可以根据需要使用任意多                的额外文件。         --gen-suppressions=<yes|no|all> [default: no]                当设置为yes时，Valgrind将会在每个错误显示之后自动暂停并且打印下                面这一行：                    ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ----                这个提示的行为和--db-attach选项(见下面)相同。                如果选择是，Valgrind会打印出一个错误的禁止条目，你可以把它剪切然后                粘帖到一个文件，如果不希望在将来再看到这个错误信息。                当设置为all时，Valgrind会对每一个错误打印一条禁止条目，而不向用户                询问。                这个选项对C++程序非常有用，它打印出编译器调整过的名字。                注意打印出来的禁止条目是尽可能的特定的。如果需要把类似的条目归纳                起来，比如在函数名中添加通配符。并且，有些时候两个不同的错误也会                产生同样的禁止条目，这时Valgrind就会输出禁止条目不止一次，但是在                禁止条目的文件中只需要一份拷贝(但是如果多于一份也不会引起什么问                题)。并且，禁止条目的名字像<在这儿输入一个禁止条目的名字>;名字并                不是很重要，它只是和-v选项一起使用打印出所有使用的禁止条目记录。         --db-attach=<yes|no> [default: no]                当这个选项打开时，Valgrind将会在每次打印错误时暂停并打出如下                一行：                    ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ----                按下回车,或者N、回车，n、回车，Valgrind不会对这个错误启动调试器。                按下Y、回车，或者y、回车，Valgrind会启动调试器并设定在程序运行的                这个点。当调试结束时，退出，程序会继续运行。在调试器内部尝试继续                运行程序，将不会生效。                按下C、回车，或者c、回车，Valgrind不会启动一个调试器，并且不会再                次询问。                注意：--db-attach=yes与--trace-children=yes有冲突。你不能同时使用                它们。Valgrind在这种情况下不能启动。                2002.05: 这是一个历史的遗留物，如果这个问题影响到你，请发送邮件并                投诉这个问题。                2002.11:如果你发送输出到日志文件或者到网络端口，我猜这不会让你有                任何感觉。不须理会。         --db-command=<command> [default: gdb -nw %f %p]                通过--db-attach指定如何使用调试器。默认的调试器是gdb.默认的选项                是一个运行时扩展Valgrind的模板。 %f会用可执行文件的文件名替换，                %p会被可执行文件的进程ID替换。                这指定了Valgrind将怎样调用调试器。默认选项不会因为在构造时是否检                测到了GDB而改变,通常是/usr/bin/gdb.使用这个命令，你可以指定一些                调用其它的调试器来替换。                给出的这个命令字串可以包括一个或多个%p %f扩展。每一个%p实例都被                解释成将调试的进程的PID，每一个%f实例都被解释成要调试的进程的可                执行文件路径。                     --input-fd=<number> [default: 0, stdin]                使用--db-attach=yes和--gen-suppressions=yes选项，在发现错误时，                Valgrind会停下来去读取键盘输入。默认地，从标准输入读取，所以关闭                了标准输入的程序会有问题。这个选项允许你指定一个文件描述符来替代                标准输入读取。         --max-stackframe=<number> [default: 2000000]                栈的最大值。如果栈指针的偏移超过这个数量，Valgrind则会认为程序是                切换到了另外一个栈执行。                如果在程序中有大量的栈分配的数组，你可能需要使用这个选项。                valgrind保持对程序栈指针的追踪。如果栈指针的偏移超过了这个数量，                Valgrind假定你的程序切换到了另外一个栈，并且Memcheck行为与栈指                针的偏移没有超出这个数量将会不同。通常这种机制运转得很好。然而，                如果你的程序在栈上申请了大的结构，这种机制将会表现得愚蠢，并且                Memcheck将会报告大量的非法栈内存访问。这个选项允许把这个阀值设置                为其它值。                应该只在Valgrind的调试输出中显示需要这么做时才使用这个选项。在这                种情况下，它会告诉你应该指定的新的阀值。                普遍地，在栈中分配大块的内存是一个坏的主意。因为这很容易用光你的                栈空间，尤其是在内存受限的系统或者支持大量小堆栈的线程的系统上，                因为Memcheck执行的错误检查，对于堆上的数据比对栈上的数据要高效                很多。如果你使用这个选项，你可能希望考虑重写代码在堆上分配内存                而不是在栈上分配。  MALLOC()相关的选项:         对于使用自有版本的malloc() (例如Memcheck和massif)，下面的选项可以使用。         --alignment=<number> [default: 8]                默认Valgrind的malloc(),realloc(), 等等，是8字节对齐地址的。这                是大部分处理器的标准。然而，一些程序可能假定malloc()等总是返回                16字节或更多对齐的内存。提供的数值必须在8和4096区间之内，并且                必须是2的幂数。  非通用选项：         这些选项可以用于所有的工具，它们影响Valgrind core的几个特性。大部分人不         会用到这些选项。         --run-libc-freeres=<yes|no> [default: yes]  　　　　GNU C库(libc.so)，所有程序共用的，可能会分配一部分内存自已用。通                常在程序退出时释放内存并不麻烦 -- 这里没什么问题，因为Linux内核在                一个进程退出时会回收进程全部的资源，所以这只是会造成速度慢。                              glibc的作者认识到这样会导致内存检查器，像Valgrind，在退出时检查                内存错误的报告glibc的内存泄漏问题，为了避免这个问题，他们提供了                一个__libc_freeres()例程特别用来让glibc释放分配的所有内存。                因此Memcheck在退出时尝试着去运行__libc_freeres()。                不幸的是，在glibc的一些版本中，__libc_freeres是有bug会导致段错误的。                这在Red Hat 7.1上有特别声明。所以，提供这个选项来决定是否运行                __libc_freeres。如果你的程序看起来在Valgrind上运行得很好，但是在                退出时发生段错误，你可能需要指定--run-libc-freeres=no来修正，这将                可能错误的报告libc.so的内存泄漏。         --sim-hints=hint1,hint2,...                传递杂凑的提示给Valgrind，轻微的修改模拟行为的非标准或危险方式，                可能有助于模拟奇怪的特性。默认没有提示打开。小心使用！目前已知                的提示有：                o lax-ioctls: 对ioctl的处理非常不严格，唯一的假定是大小是正确的。                不需要在写时缓冲区完全的初始化。没有这个，用大量的奇怪的ioctl                命令来使用一些设备驱动将会非常烦人。                o enable-inner:打开某些特殊的效果，当运行的程序是Valgrind自身时。         --kernel-variant=variant1,variant2,...                处理系统调用和ioctls在这个平台的默认核心上产生不同的变量。这有助                于运行在改进过的内核或者支持非标准的ioctls上。小心使用。如果你不                理解这个选项做的是什么那你几乎不需要它。已经知道的变量有：                o bproc: 支持X86平台上的sys_broc系统调用。这是为了运行在BProc，                它是标准Linux的一个变种，有时用来构建集群。         --show-emwarns=<yes|no> [default: no]                当这个选项打开时，Valgrind在一些特定的情况下将对CPU仿真产生警告。                通常这些都是不引人注意的。         --smc-check=<none|stack|all> [default: stack]                这个选项控制Valgrind对自我修改的代码的检测。Valgrind可以不做检测，                可以检测栈中自我修改的代码，或者任意地方检测自我修改的代码。注意                默认选项是捕捉绝大多数情况，到目前我们了解的情况为止。使用all选项                时会极大的降低速度。(但是用none选项运行极少影响速度，因为对大多数                程序，非常少的代码被添加到栈中)  调试VALGRIND选项：         还有一些选项是用来调试Valgrind自身的。在运行一般的东西时不应该需要的。         如果你希望看到选项列表，使用--help-debug选项。  内存检查选项：         --leak-check=<no|summary|yes|full> [default: summary]                当这个选项打开时，当客户程序结束时查找内存泄漏。内存泄漏意味着                有用malloc分配内存块，但是没有用free释放，而且没有指针指向这块                内存。这样的内存块永远不能被程序释放，因为没有指针指向它们。如                果设置为summary，Valgrind会报告有多少内存泄漏发生了。如果设置为                full或yes，Valgrind给出每一个独立的泄漏的详细信息。         --show-reachable=<yes|no> [default: no]                当这个选项关闭时，内存泄漏检测器只显示没有指针指向的内存块，或                者只能找到指向块中间的指针。当这个选项打开时，内存泄漏检测器还                报告有指针指向的内存块。这些块是最有可能出现内存泄漏的地方。你                的程序可能，至少在原则上，应该在退出前释放这些内存块。这些有指                针指向的内存块和没有指针指向的内存块，或者只有内部指针指向的块，                都可能产生内存泄漏，因为实际上没有一个指向块起始的指针可以拿来释                放，即使你想去释放它。         --leak-resolution=<low|med|high> [default: low]                在做内存泄漏检查时，确定memcheck将怎么样考虑不同的栈是相同的情况。                当设置为low时，只需要前两层栈匹配就认为是相同的情况；当设置为med，                必须要四层栈匹配，当设置为high时，所有层次的栈都必须匹配。                              对于hardcore内存泄漏检查，你很可能需要使用--leak-resolution=high和                --num-callers=40或者更大的数字。注意这将产生巨量的信息，这就是为什                么默认选项是四个调用者匹配和低分辨率的匹配。                注意--leak-resolution= 设置并不影响memcheck查找内存泄漏的能力。它                只是改变了结果如何输出。         --freelist-vol=<number> [default: 5000000]                当客户程序使用free(C中)或者delete(C++)释放内存时，这些内存并不是                马上就可以用来再分配的。这些内存将被标记为不可访问的，并被放到一                个已释放内存的队列中。这样做的目的是，使释放的内存再次被利用的点                尽可能的晚。这有利于memcheck在内存块释放后这段重要的时间检查对块                不合法的访问。                这个选项指定了队列所能容纳的内存总容量，以字节为单位。默认的值是                5000000字节。增大这个数目会增加memcheck使用的内存，但同时也增加了                对已释放内存的非法使用的检测概率。         --workaround-gcc296-bugs=<yes|no> [default: no]                当这个选项打开时，假定读写栈指针以下的一小段距离是gcc 2.96的bug，                并且不报告为错误。距离默认为256字节。注意gcc 2.96是一些比较老的                Linux发行版(RedHat 7.X)的默认编译器，所以你可能需要使用这个选项。                如果不是必要请不要使用这个选项，它可能会使一些真正的错误溜掉。                一个更好的解决办法是使用较新的，修正了这个bug的gcc/g++版本。         --partial-loads-ok=<yes|no> [default: no]                控制memcheck如何处理从地址读取时字长度，字对齐，因此哪些字节是可                以寻址的，哪些是不可以寻址的。当设置为yes是，这样的读取并不抛出                一个寻址错误。而是从非法地址读取的V字节显示为未定义，访问                合法地址仍然是像平常一样映射到内存。                设置为no时，从部分错误的地址读取与从完全错误的地址读取同样处理：                抛出一个非法地址错误，结果的V字节显示为合法数据。                注意这种代码行为是违背ISO C/C++标准，应该被认为是有问题的。如果可                能，这种代码应该修正。这个选项应该只是做为一个最后考虑的方法。         --undef-value-errors=<yes|no> [default: yes]                控制memcheck是否检查未定义值的危险使用。当设为yes时，Memcheck的行                为像Addrcheck, 一个轻量级的内存检查工具，是Valgrind的一个部分，它                并不检查未定义值的错误。使用这个选项，如果你不希望看到未定义值错误。  CACHEGRIND选项：         手动指定I1/D1/L2缓冲配置，大小是用字节表示的。这三个必须用逗号隔开，中间         没有空格，例如：             valgrind --tool=cachegrind --I1=65535,2,64         你可以指定一个，两个或三个I1/D1/L2缓冲。如果没有手动指定，每个级别使用         普通方式(通过CPUID指令得到缓冲配置，如果失败，使用默认值)得到的配置。         --I1=<size>,<associativity>,<line size>                指定第一级指令缓冲的大小，关联度和行大小。         --D1=<size>,<associativity>,<line size>                指定第一级数据缓冲的大小，关联度和行大小。         --L2=<size>,<associativity>,<line size>                指定第二级缓冲的大小，关联度和行大小。  CALLGRIND选项：         --heap=<yes|no> [default: yes]                当这个选项打开时，详细的追踪堆的使用情况。关闭这个选项时，                massif.pid.txt或massif.pid.html将会非常的简短。         --heap-admin=<number> [default: 8]                每个块使用的管理字节数。这只能使用一个平均的估计值，因为它可能变化。                glibc使用的分配器每块需要4~15字节，依赖于各方面的因素。管理已经释放                的块也需要空间，尽管massif不计算这些。                     --stacks=<yes|no> [default: yes]                当打开时，在剖析信息中包含栈信息。多线程的程序可能有多个栈。         --depth=<number> [default: 3]                详细的堆信息中调用过程的深度。增加这个值可以给出更多的信息，但是                massif会更使这个程序运行得慢，使用更多的内存，并且产生一个大的                massif.pid.txt或者massif.pid.hp文件。         --alloc-fn=<name>                指定一个分配内存的函数。这对于使用malloc()的包装函数是有用的，可以                用它来填充原来无效的上下文信息。(这些函数会给出无用的上下文信息，                并在图中给出无意义的区域)。指定的函数在上下文中被忽略，例如，像对                malloc()一样处理。这个选项可以在命令行中重复多次，指定多个函数。         --format=<text|html> [default: text]                产生text或者HTML格式的详细堆信息，文件的后缀名使用.txt或者.html。  HELGRIND选项：         --private-stacks=<yes|no> [default: no]                假定线程栈是私有的。         --show-last-access=<yes|some|no> [default: no]                显示最后一次字访问出错的位置。  LACKEY选项：         --fnname=<name> [default: _dl_runtime_resolve()]                对<name>函数计数。         --detailed-counts=<no|yes> [default: no]                对读取，存储和alu操作计数。 

Valgrind 使用举例（一）

下面是一段有问题的C程序代码test.c

＃i nclude <stdlib.h> void f(void) { int* x = malloc(10 * sizeof(int)); x[10] = 0; //问题1: 数组下标越界 } //问题2: 内存没有释放 int main(void) { f(); return 0; } 1、 编译程序test.c gcc -Wall test.c -g -o test 2、 使用Valgrind检查程序BUG valgrind --tool=memcheck --leak-check=full ./test

使用未初始化内存问题

问题分析：

对于位于程序中不同段的变量，其初始值是不同的，全局变量和静态变量初始值为0，而局部变量和动态申请的变量，其初始值为随机值。如果程序使用了为随机值的变量，那么程序的行为就变得不可预期。

下面的程序就是一种常见的，使用了未初始化的变量的情况。数组a是局部变量，其初始值为随机值，而在初始化时并没有给其所有数组成员初始化，如此在接下来使用这个数组时就潜在有内存问题。  

结果分析：

假设这个文件名为：badloop.c，生成的可执行程序为badloop。用memcheck对其进行测试，输出如下。  

输出结果显示，在该程序第11行中，程序的跳转依赖于一个未初始化的变量。准确的发现了上述程序中存在的问题。

内存读写越界

问题分析：

这种情况是指：访问了你不应该/没有权限访问的内存地址空间，比如访问数组时越界；对动态内存访问时超出了申请的内存大小范围。下面的程序就是一个典型的数组越界问题。pt是一个局部数组变量，其大小为4，p初始指向pt数组的起始地址，但在对p循环叠加后，p超出了pt数组的范围，如果此时再对p进行写操作，那么后果将不可预期。  

结果分析：

假设这个文件名为badacc.cpp，生成的可执行程序为badacc，用memcheck对其进行测试，输出如下。  

输出结果显示，在该程序的第15行，进行了非法的写操作；在第16行，进行了非法读操作。准确地发现了上述问题。

内存覆盖

问题分析：

C 语言的强大和可怕之处在于其可以直接操作内存，C 标准库中提供了大量这样的函数，比如 strcpy, strncpy, memcpy, strcat 等，这些函数有一个共同的特点就是需要设置源地址 (src)，和目标地址(dst)，src 和 dst 指向的地址不能发生重叠，否则结果将不可预期。

下面就是一个 src 和 dst 发生重叠的例子。在 15 与 17 行中，src 和 dst 所指向的地址相差 20，但指定的拷贝长度却是 21，这样就会把之前的拷贝值覆盖。第 24 行程序类似，src(x+20) 与 dst(x) 所指向的地址相差 20，但 dst 的长度却为 21，这样也会发生内存覆盖。  

结果分析：

假设这个文件名为 badlap.cpp，生成的可执行程序为 badlap，用 memcheck 对其进行测试，输出如下。  

输出结果显示上述程序中第15，17，24行，源地址和目标地址设置出现重叠。准确的发现了上述问题。

动态内存管理错误

问题分析：

常见的内存分配方式分三种：静态存储，栈上分配，堆上分配。全局变量属于静态存储，它们是在编译时就被分配了存储空间，函数内的局部变量属于栈上分配，而最灵活的内存使用方式当属堆上分配，也叫做内存动态分配了。常用的内存动态分配函数包括：malloc, alloc, realloc, new等，动态释放函数包括free, delete。

一旦成功申请了动态内存，我们就需要自己对其进行内存管理，而这又是最容易犯错误的。下面的一段程序，就包括了内存动态管理中常见的错误。  

常见的内存动态管理错误包括：

  申请和释放不一致

由于 C++ 兼容 C，而 C 与 C++ 的内存申请和释放函数是不同的，因此在 C++ 程序中，就有两套动态内存管理函数。一条不变的规则就是采用 C 方式申请的内存就用 C 方式释放；用 C++ 方式申请的内存，用 C++ 方式释放。也就是用 malloc/alloc/realloc 方式申请的内存，用 free 释放；用 new 方式申请的内存用 delete 释放。在上述程序中，用 malloc 方式申请了内存却用 delete 来释放，虽然这在很多情况下不会有问题，但这绝对是潜在的问题。

  申请和释放不匹配

申请了多少内存，在使用完成后就要释放多少。如果没有释放，或者少释放了就是内存泄露；多释放了也会产生问题。上述程序中，指针p和pt指向的是同一块内存，却被先后释放两次。

  释放后仍然读写

本质上说，系统会在堆上维护一个动态内存链表，如果被释放，就意味着该块内存可以继续被分配给其他部分，如果内存被释放后再访问，就可能覆盖其他部分的信息，这是一种严重的错误，上述程序第16行中就在释放后仍然写这块内存。

结果分析：

假设这个文件名为badmac.cpp，生成的可执行程序为badmac，用memcheck对其进行测试，输出如下。  

输出结果显示，第14行分配和释放函数不一致；第16行发生非法写操作，也就是往释放后的内存地址写值；第17行释放内存函数无效。准确地发现了上述三个问题。

内存泄漏

问题描述：

内存泄露（Memory leak）指的是，在程序中动态申请的内存，在使用完后既没有释放，又无法被程序的其他部分访问。内存泄露是在开发大型程序中最令人头疼的问题，以至于有人说，内存泄露是无法避免的。其实不然，防止内存泄露要从良好的编程习惯做起，另外重要的一点就是要加强单元测试（Unit Test），而memcheck就是这样一款优秀的工具。

下面是一个比较典型的内存泄露案例。main函数调用了mk函数生成树结点，可是在调用完成之后，却没有相应的函数：nodefr释放内存，这样内存中的这个树结构就无法被其他部分访问，造成了内存泄露。

在一个单独的函数中，每个人的内存泄露意识都是比较强的。但很多情况下，我们都会对malloc/free 或new/delete做一些包装，以符合我们特定的需要，无法做到在一个函数中既使用又释放。这个例子也说明了内存泄露最容易发生的地方：即两个部分的接口部分，一个函数申请内存，一个函数释放内存。并且这些函数由不同的人开发、使用，这样造成内存泄露的可能性就比较大了。这需要养成良好的单元测试习惯，将内存泄露消灭在初始阶段。      

结果分析：

假设上述文件名位tree.h, tree.cpp, badleak.cpp，生成的可执行程序为badleak，用memcheck对其进行测试，输出如下。

 

该示例程序是生成一棵树的过程，每个树节点的大小为12（考虑内存对齐），共8个节点。从上述输出可以看出，所有的内存泄露都被发现。Memcheck将内存泄露分为两种，一种是可能的内存泄露（Possibly lost），另外一种是确定的内存泄露（Definitely lost）。Possibly lost 是指仍然存在某个指针能够访问某块内存，但该指针指向的已经不是该内存首地址。Definitely lost 是指已经不能够访问这块内存。而Definitely lost又分为两种：直接的（direct）和间接的（indirect）。直接和间接的区别就是，直接是没有任何指针指向该内存，间接是指指向该内存的指针都位于内存泄露处。在上述的例子中，根节点是directly lost，而其他节点是indirectly lost。

zz自 http://blog.csdn.net/destina/article/details/6198443  感谢作者的分享！