Linux Server 程序内存检测好助手-Valgrind(转载) C/C++ 2009-09-07 17:05:38 阅读387 评论0 字号：大中小 订阅 Valgrind工具包包含多个工具，如Memcheck,Cachegrind,Helgrind, Callgrind，Massif。下面分别介绍个工具的作用： Memcheck 工具主要检查下面的程序错误： 使用未初始化的内存 (Use of uninitialised memory) 使用已经释放了的内存 (Reading/writing memory after it has been free’d) 使用超过 malloc分配的内存空间(Reading/writing off the end of malloc’d blocks) 对堆栈的非法访问 (Reading/writing inappropriate areas on the stack) 申请的空间是否有释放 (Memory leaks – where pointers to malloc’d blocks are lost forever) malloc/free/new/delete申请和释放内存的匹配(Mismatched use of malloc/new/new [] vs free/delete/delete []) src和dst的重叠(Overlapping src and dst pointers in memcpy() and related functions) Callgrind Callgrind收集程序运行时的一些数据，函数调用关系等信息，还可以有选择地进行cache 模拟。在运行结束时，它会把分析数据写入一个文件。callgrind_annotate可以把这个文件的内容转化成可读的形式。 Cachegrind 它模拟 CPU中的一级缓存I1,D1和L2二级缓存，能够精确地指出程序中 cache的丢失和命中。如果需要，它还能够为我们提供cache丢失次数，内存引用次数，以及每行代码，每个函数，每个模块，整个程序产生的指令数。这对优化程序有很大的帮助。 Helgrind 它主要用来检查多线程程序中出现的竞争问题。Helgrind 寻找内存中被多个线程访问，而又没有一贯加锁的区域，这些区域往往是线程之间失去同步的地方，而且会导致难以发掘的错误。Helgrind实现了名为” Eraser” 的竞争检测算法，并做了进一步改进，减少了
报告
软件系统测试报告下载sgs报告如何下载关于路面塌陷情况报告535n,sgs报告怎么下载竣工报告下载
错误的次数。 Massif 堆栈分析器，它能测量程序在堆栈中使用了多少内存，告诉我们堆块，堆管理块和栈的大小。Massif能帮助我们减少内存的使用，在带有虚拟内存的现代系统中，它还能够加速我们程序的运行，减少程序停留在交换区中的几率。 Valgrind 安装 1、 到www.valgrind.org下载最新版valgrind-3.2.3.tar.bz2 2、 解压安装包：tar –jxvf valgrind-3.2.3.tar.bz2 3、 解压后生成目录valgrind-3.2.3 4、 cd valgrind-3.2.3 5、 ./configure 6、 Make;make install Valgrind 使用 用法: valgrind [options] prog-and-args [options]: 常用选项，适用于所有Valgrind工具 1. -tool=
最常用的选项。运行 valgrind中名为toolname的工具。默认memcheck。 2. h –help 显示帮助信息。 3. -version 显示valgrind内核的版本，每个工具都有各自的版本。 4. q –quiet 安静地运行，只打印错误信息。 5. v –verbose 更详细的信息, 增加错误数统计。 6. -trace-children=no|yes 跟踪子线程? [no] 7. -track-fds=no|yes 跟踪打开的文件描述？[no] 8. -time-stamp=no|yes 增加时间戳到LOG信息? [no] 9. -log-fd= 输出LOG到描述符文件 [2=stderr] 10. -log-file= 将输出的信息写入到filename.PID的文件里，PID是运行程序的进行ID 11. -log-file-exactly= 输出LOG信息到 file 12. -log-file-qualifier= 取得环境变量的值来做为输出信息的文件名。 [none] 13. -log-socket=ipaddr:port 输出LOG到socket ，ipaddr:port LOG信息输出 1. -xml=yes 将信息以xml格式输出，只有memcheck可用 2. -num-callers= show callers in stack traces [12] 3. -error-limit=no|yes 如果太多错误，则停止显示新错误? [yes] 4. -error-exitcode= 如果发现错误则返回错误代码 [0=disable] 5. -db-attach=no|yes 当出现错误，valgrind会自动启动调试器gdb。[no] 6. -db-command= 启动调试器的命令行选项[gdb -nw %f %p] 适用于Memcheck工具的相关选项： 1. -leak-check=no|summary|full 要求对leak给出详细信息? [summary] 2. -leak-resolution=low|med|high how much bt merging in leak check [low] 3. -show-reachable=no|yes show reachable blocks in leak check? [no] Valgrind 使用举例 下面是一段有问题的C程序代码test.c #include 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 3、 分析输出的调试信息 ==3908== Memcheck, a memory error detector. ==3908== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==3908== Using LibVEX rev 1732, a library for dynamic binary translation. ==3908== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==3908== Using valgrind-3.2.3, a dynamic binary instrumentation framework. ==3908== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==3908== For more details, rerun with: -v ==3908== --3908-- DWARF2 CFI reader: unhandled CFI instruction 0:50 --3908-- DWARF2 CFI reader: unhandled CFI instruction 0:50 /*数组越界错误*/ ==3908== Invalid write of size 4 ==3908== at 0x8048384: f (test.c:6) ==3908== by 0x80483AC: main (test.c:11) ==3908== Address 0x400C050 is 0 bytes after a block of size 40 alloc'd ==3908== at 0x40046F2: malloc (vg_replace_malloc.c:149) ==3908== by 0x8048377: f (test.c:5) ==3908== by 0x80483AC: main (test.c:11) ==3908== ==3908== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 14 from 1) ==3908== malloc/free: in use at exit: 40 bytes in 1 blocks. ==3908== malloc/free: 1 allocs, 0 frees, 40 bytes allocated. ==3908== For counts of detected errors, rerun with: -v ==3908== searching for pointers to 1 not-freed blocks. ==3908== checked 59,124 bytes. ==3908== ==3908== /*有内存空间没有释放*/ ==3908== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==3908== at 0x40046F2: malloc (vg_replace_malloc.c:149) ==3908== by 0x8048377: f (test.c:5) ==3908== by 0x80483AC: main (test.c:11) ==3908== ==3908== LEAK SUMMARY: ==3908== definitely lost: 40 bytes in 1 blocks. ==3908== possibly lost: 0 bytes in 0 blocks. ==3908== still reachable: 0 bytes in 0 blocks. ==3908== suppressed: 0 bytes in 0 blocks. 用C/C++开发其中最令人头疼的一个问题就是内存管理，有时候为了查找一个内存泄漏或者一个内存访问越界，需要要花上好几天时间，如果有一款工具能够帮助我们做这件事情就好了，valgrind正好就是这样的一款工具。 Valgrind是一款基于模拟linux下的程序调试器和剖析器的软件套件，可以运行于 x86, amd64和ppc32架构上。valgrind包含一个核心，它提供一个虚拟的CPU运行程序，还有一系列的工具，它们完成调试，剖析和一些类似的任 务。valgrind是高度模块化的，所以开发人员或者用户可以给它添加新的工具而不会损坏己有的结构。 valgrind的官方网址是：http://valgrind.org 你可以在它的网站上下载到最新的valgrind，它是开放源码和免费的。 一、介绍 valgrind包含几个标准的工具，它们是： 1、memcheck memcheck探测程序中内存管理存在的问题。它检查所有对内存的读/写操作，并截取所有的malloc/new/free/delete调用。因此memcheck工具能够探测到以下问题： 1）使用未初始化的内存 2）读/写已经被释放的内存 3）读/写内存越界 4）读/写不恰当的内存栈空间 5）内存泄漏 6）使用malloc/new/new[]和free/delete/delete[]不匹配。 2、cachegrind cachegrind是一个cache剖析器。它模拟执行CPU中的L1, D1和L2 cache，因此它能很精确的指出代码中的cache未命中。如果你需要，它可以打印出cache未命中的次数，内存引用和发生cache未命中的每一行 代码，每一个函数，每一个模块和整个程序的摘要。如果你要求更细致的信息，它可以打印出每一行机器码的未命中次数。在x86和amd64上， cachegrind通过CPUID自动探测机器的cache配置，所以在多数情况下它不再需要更多的配置信息了。 3、helgrind helgrind查找多线程程序中的竞争数据。helgrind查找内存地址，那些被多于一条线程访问的内存地址，但是没有使用一致的锁就会被查出。这表示这些地址在多线程间访问的时候没有进行同步，很可能会引起很难查找的时序问题。 二、valgrind对你的程序都做了些什么 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选项来运行脚本。 下面是用memcheck检查ls -l命令的输出报告，在终端下执行下面的命令 valgrind --tool=memcheck ls -l 程序会打印出ls -l命令的结果，最后是valgrind的检查报告如下： ==4187== ==4187== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 19 from 2) ==4187== malloc/free: in use at exit: 15,154 bytes in 105 blocks. ==4187== malloc/free: 310 allocs, 205 frees, 60,093 bytes allocated. ==4187== For counts of detected errors, rerun with: -v ==4187== searching for pointers to 105 not-freed blocks. ==4187== checked 145,292 bytes. ==4187== ==4187== LEAK SUMMARY: ==4187== definitely lost: 0 bytes in 0 blocks. ==4187== possibly lost: 0 bytes in 0 blocks. ==4187== still reachable: 15,154 bytes in 105 blocks. ==4187== suppressed: 0 bytes in 0 blocks. ==4187== Reachable blocks (those to which a pointer was found) are not shown. ==4187== To see them, rerun with: --show-reachable=yes 这里的“4187”指的是执行ls -l的进程ID，这有利于区别不同进程的报告。memcheck会给出报告，分配置和释放了多少内存，有多少内存泄漏了，还有多少内存的访问是可达的，检查了多少字节的内存。 下面举两个用valgrind做内存检查的例子 例子一 (test.c)： #include int main(int argc, char *argv[]) { char *ptr; ptr = (char*) malloc(10); strcpy(ptr, "01234567890"); return 0; } 编译程序 gcc -g -o test test.c 用valgrind执行命令 valgrind --tool=memcheck --leak-check=yes ./test 报告如下 ==4270== Memcheck, a memory error detector. ==4270== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==4270== Using LibVEX rev 1606, a library for dynamic binary translation. ==4270== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==4270== Using valgrind-3.2.0, a dynamic binary instrumentation framework. ==4270== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==4270== For more details, rerun with: -v ==4270== ==4270== Invalid write of size 1 ==4270== at 0x4006190: strcpy (mc_replace_strmem.c:271) ==4270== by 0x80483DB: main (test.c:8) ==4270== Address 0x4023032 is 0 bytes after a block of size 10 alloc'd ==4270== at 0x40044F6: malloc (vg_replace_malloc.c:149) ==4270== by 0x80483C5: main (test.c:7) ==4270== ==4270== Invalid write of size 1 ==4270== at 0x400619C: strcpy (mc_replace_strmem.c:271) ==4270== by 0x80483DB: main (test.c:8) ==4270== Address 0x4023033 is 1 bytes after a block of size 10 alloc'd ==4270== at 0x40044F6: malloc (vg_replace_malloc.c:149) ==4270== by 0x80483C5: main (test.c:7) ==4270== ==4270== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 12 from 1) ==4270== malloc/free: in use at exit: 10 bytes in 1 blocks. ==4270== malloc/free: 1 allocs, 0 frees, 10 bytes allocated. ==4270== For counts of detected errors, rerun with: -v ==4270== searching for pointers to 1 not-freed blocks. ==4270== checked 51,496 bytes. ==4270== ==4270== ==4270== 10 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==4270== at 0x40044F6: malloc (vg_replace_malloc.c:149) ==4270== by 0x80483C5: main (test.c:7) ==4270== ==4270== LEAK SUMMARY: ==4270== definitely lost: 10 bytes in 1 blocks. ==4270== possibly lost: 0 bytes in 0 blocks. ==4270== still reachable: 0 bytes in 0 blocks. ==4270== suppressed: 0 bytes in 0 blocks. ==4270== Reachable blocks (those to which a pointer was found) are not shown. ==4270== To see them, rerun with: --show-reachable=yes 从这份报告可以看出，进程号是4270，test.c的第8行写内存越界了，引起写内存越界的是strcpy函数， 第7行泄漏了10个字节的内存，引起内存泄漏的是malloc函数。 例子二（test2.c) #include int foo(int x) { if (x < 0) { printf("%d ", x); } return 0; } int main(int argc, char *argv[]) { int x; foo(x); return 0; } 编译程序 gcc -g -o test2 test2.c 用valgrind做内存检查 valgrind --tool=memcheck ./test2 输出报告如下 ==4285== Memcheck, a memory error detector. ==4285== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==4285== Using LibVEX rev 1606, a library for dynamic binary translation. ==4285== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==4285== Using valgrind-3.2.0, a dynamic binary instrumentation framework. ==4285== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==4285== For more details, rerun with: -v ==4285== ==4285== Conditional jump or move depends on uninitialised value(s) ==4285== at 0x8048372: foo (test2.c:5) ==4285== by 0x80483B4: main (test2.c:16) ==4285==p p ==4285== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 12 from 1) ==4285== malloc/free: in use at exit: 0 bytes in 0 blocks. ==4285== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==4285== For counts of detected errors, rerun with: -v ==4285== All heap blocks were freed -- no leaks are possible. 从这份报告可以看出进程PID是4285，test2.c文件的第16行调用了foo函数，在test2.c文件的第5行foo函数使用了一个未初始化的变量。 valgrind还有很多使用选项，具体可以查看valgrind的man
手册
华为质量管理手册 下载焊接手册下载团建手册下载团建手册下载ld手册下载
页和valgrind官方网站的在线文档。 附录A：参数指令 基本选项： 这些选项对所有工具都有效。 -h --help 显示所有选项的帮助，包括内核和选定的工具两者。 --help-debug 和--help相同，并且还能显示通常只有Valgrind的开发人员使用的调试选项。 --version 显示Valgrind内核的版本号。工具可以有他们自已的版本号。这是一种保证工具只在它们可以运行的内核上工作的一种设置。这样可以减少在工具和内核之间版本兼容性导致奇怪问题的概率。 -q --quiet 安静的运行，只打印错误信息。在进行回归测试或者有其它的自动化测试机制时会非常有用。 -v --verbose 显示详细信息。在各个方面显示你的程序的额外信息，例如：共享对象加载，使用的重置，执行引擎和工具的进程，异常行为的警告信息。重复这个标记可以增加详细的级别。 -d 调试Valgrind自身发出的信息。通常只有Valgrind开发人员对此感兴趣。重复这个标记可以产生更详细的输出。如果你希望发送一个bug报告，通过-v -v -d -d生成的输出会使你的报告更加有效。 --tool= [default: memcheck] 运行toolname指定的Valgrind，例如，Memcheck, Addrcheck, Cachegrind,等等。 --trace-children= [default: no] 当这个选项打开时，Valgrind会跟踪到子进程中。这经常会导致困惑，而且通常不是你所期望的，所以默认这个选项是关闭的。 --track-fds= [default: no] 当这个选项打开时，Valgrind会在退出时打印一个打开文件描述符的列表。每个文件描述符都会打印出一个文件是在哪里打开的栈回溯，和任何与此文件描述符相关的详细信息比如文件名或socket信息。 --time-stamp= [default: no] 当这个选项打开时，每条信息之前都有一个从程序开始消逝的时间，用天，小时，分钟，秒和毫秒表示。 --log-fd= [default: 2, stderr] 指定Valgrind把它所有的消息都输出到一个指定的文件描述符中去。默认值2, 是标准错误输出(stderr)。注意这可能会干扰到客户端自身对stderr的使用, Valgrind的输出与客户程序的输出将穿插在一起输出到stderr。 --log-file= 指定Valgrind把它所有的信息输出到指定的文件中。实际上，被创建文件的文件名是由filename、'.'和进程号连接起来的（即.），从而每个进程创建不同的文件。 --log-file-exactly= 类似于--log-file，但是后缀".pid"不会被添加。如果设置了这个选项，使用Valgrind跟踪多个进程，可能会得到一个乱七八糟的文件。 --log-file-qualifier= 当和--log-file一起使用时，日志文件名将通过环境变量$VAR来筛选。这对于MPI程序是有益的。更多的细节，查看手册2.3节 "注解"。 --log-socket= 指 定Valgrind输出所有的消息到指定的IP，指定的端口。当使用1500端口时，端口有可能被忽略。如果不能建立一个到指定端口的连 接，Valgrind将输出写到标准错误(stderr)。这个选项经常和一个Valgrind监听程序一起使用。更多的细节，查看手册2.3节 "注解"。 错误相关选项： 这些选项适用于所有产生错误的工具，比如Memcheck, 但是Cachegrind不行。 --xml= [default: no] 当这个选项打开时，输出将是XML格式。这是为了使用Valgrind的输出做为输入的工具，例如GUI前端更加容易些。目前这个选项只在Memcheck时生效。 --xml-user-comment= 在XML开头 附加用户注释，仅在指定了--xml=yes时生效，否则忽略。 --demangle= [default: yes] 打 开/关闭C++的名字自动解码。默认打开。当打开时，Valgrind将尝试着把编码过的C++名字自动转回初始状态。这个解码器可以处理g++版本为 2.X,3.X或4.X生成的符号。一个关于名字编码解码重要的事实是，禁止文件中的解码函数名仍然使用他们未解码的形式。Valgrind在搜寻可用的 禁止条目时不对函数名解码，因为这将使禁止文件内容依赖于Valgrind的名字解码机制状态，会使速度变慢，且无意义。 --num-callers= [default: 12] 默 认情况下，Valgrind显示12层函数调用的函数名有助于确定程序的位置。可以通过这个选项来改变这个数字。这样有助在嵌套调用的层次很深时确定程序 的位置。注意错误信息通常只回溯到最顶上的4个函数。(当前函数，和它的3个调用者的位置)。所以这并不影响报告的错误总数。这个值的最大值是50。注意 高的设置会使Valgrind运行得慢，并且使用更多的内存,但是在嵌套调用层次比较高的程序中非常实用。 --error-limit= [default: yes] 当这个选项打开时，在总量达到10,000,000，或者1,000个不同的错误，Valgrind停止报告错误。这是为了避免错误跟踪机制在错误很多的程序下变成一个巨大的性能负担。 --error-exitcode= [default: 0] 指 定如果Valgrind在运行过程中报告任何错误时的退出返回值，有两种情况；当设置为默认值(零)时，Valgrind返回的值将是它模拟运行的程序的 返回值。当设置为非零值时，如果Valgrind发现任何错误时则返回这个值。在Valgrind做为一个测试工具套件的部分使用时这将非常有用，因为使 测试工具套件只检查Valgrind返回值就可以知道哪些测试用例Valgrind报告了错误。 --show-below-main= [default: no] 默认地，错误时的栈回溯不显示main()之下的任何函数(或者类似的函数像glibc的__libc_start_main()，如果main()没有出现在栈回溯中)；这些大部分都是令人厌倦的C库函数。如果打开这个选项，在main()之下的函数也将会显示。 --suppressions= [default: $PREFIX/lib/valgrind/default.supp] 指定一个额外的文件读取不需要理会的错误；你可以根据需要使用任意多的额外文件。 --gen-suppressions= [default: no] 当 设置为yes时，Valgrind将会在每个错误显示之后自动暂停并且打印下面这一行：---- Print suppression ? --- [Return/N/n/Y/y/C/c] ----这个提示的行为和--db-attach选项(见下面)相同。如果选择是，Valgrind会打印出一个错误的禁止条目，你可以把它剪切然后粘帖 到一个文件，如果不希望在将来再看到这个错误信息。当设置为all时，Valgrind会对每一个错误打印一条禁止条目，而不向用户询问。这个选项对 C++程序非常有用，它打印出编译器调整过的名字。注意打印出来的禁止条目是尽可能的特定的。如果需要把类似的条目归纳起来，比如在函数名中添加通配符。 并且，有些时候两个不同的错误也会产生同样的禁止条目，这时Valgrind就会输出禁止条目不止一次，但是在禁止条目的文件中只需要一份拷贝(但是如果 多于一份也不会引起什么问题)。并且，禁止条目的名字像<在这儿输入一个禁止条目的名字>;名字并不是很重要，它只是和-v选项一起使用打印 出所有使用的禁止条目记录。 --db-attach= [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= [default: gdb -nw %f %p] 通过--db-attach指定如何使用调试器。默认的调试器是gdb.默认的选项是一个运行时扩展Valgrind的模板。 %f会用可执行文件的文件名替换，%p会被可执行文件的进程ID替换。 这指定了Valgrind将怎样调用调试器。默认选项不会因为在构造时是否检测到了GDB而改变,通常是/usr/bin/gdb.使用这个命令，你可以指定一些调用其它的调试器来替换。 给出的这个命令字串可以包括一个或多个%p %f扩展。每一个%p实例都被解释成将调试的进程的PID，每一个%f实例都被解释成要调试的进程的可执行文件路径。 --input-fd= [default: 0, stdin] 使用--db-attach=yes和--gen-suppressions=yes选项，在发现错误时，Valgrind会停下来去读取键盘输入。默认地，从标准输入读取，所以关闭了标准输入的程序会有问题。这个选项允许你指定一个文件描述符来替代标准输入读取。 --max-stackframe= [default: 2000000] 栈 的最大值。如果栈指针的偏移超过这个数量，Valgrind则会认为程序是切换到了另外一个栈执行。如果在程序中有大量的栈分配的数组，你可能需要使用这 个选项。valgrind保持对程序栈指针的追踪。如果栈指针的偏移超过了这个数量，Valgrind假定你的程序切换到了另外一个栈，并且 Memcheck行为与栈指 针的偏移没有超出这个数量将会不同。通常这种机制运转得很好。然而，如果你的程序在栈上申请了大的结构，这 种机制将会表现得愚蠢，并且Memcheck将会报告大量的非法栈内存访问。这个选项允许把这个阀值设置为其它值。应该只在Valgrind的调试输出中 显示需要这么做时才使用这个选项。在这种情况下，它会告诉你应该指定的新的阀值。普遍地，在栈中分配大块的内存是一个坏的主意。因为这很容易用光你的栈空 间，尤其是在内存受限的系统或者支持大量小堆栈的线程的系统上，因为Memcheck执行的错误检查，对于堆上的数据比对栈上的数据要高效很多。如果你使 用这个选项，你可能希望考虑重写代码在堆上分配内存而不是在栈上分配。 MALLOC()相关的选项: 对于使用自有版本的malloc() (例如Memcheck和massif)，下面的选项可以使用。 --alignment= [default: 8] 默认Valgrind的malloc(),realloc(), 等等，是8字节对齐地址的。这是大部分处理器的标准。然而，一些程序可能假定malloc()等总是返回16字节或更多对齐的内存。提供的数值必须在8和4096区间之内，并且必须是2的幂数。 非通用选项： 这些选项可以用于所有的工具，它们影响Valgrind core的几个特性。大部分人不会用到这些选项。 --run-libc-freeres= [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，轻微的修改模拟行为的非标准或危险方式，可能有助于模拟奇怪的特性。默认没有提示打开。小心使用！目前已知的提示有： l lax-ioctls: 对ioctl的处理非常不严格，唯一的假定是大小是正确的。不需要在写时缓冲区完全的初始化。没有这个，用大量的奇怪的ioctl命令来使用一些设备驱动将会非常烦人。 l enable-inner:打开某些特殊的效果，当运行的程序是Valgrind自身时。 --kernel-variant=variant1,variant2,... 处理系统调用和ioctls在这个平台的默认核心上产生不同的变量。这有助于运行在改进过的内核或者支持非标准的ioctls上。小心使用。如果你不理解这个选项做的是什么那你几乎不需要它。已经知道的变量有： l bproc: 支持X86平台上的sys_broc系统调用。这是为了运行在BProc，它是标准Linux的一个变种，有时用来构建集群。 --show-emwarns= [default: no] 当这个选项打开时，Valgrind在一些特定的情况下将对CPU仿真产生警告。通常这些都是不引人注意的。 --smc-check= [default: stack] 这 个选项控制Valgrind对自我修改的代码的检测。Valgrind可以不做检测，可以检测栈中自我修改的代码，或者任意地方检测自我修改的代码。注意 默认选项是捕捉绝大多数情况，到目前我们了解的情况为止。使用all选项时会极大的降低速度。(但是用none选项运行极少影响速度，因为对大多数程序， 非常少的代码被添加到栈中) 调试VALGRIND选项： 还有一些选项是用来调试Valgrind自身的。在运行一般的东西时不应该需要的。如果你希望看到选项列表，使用--help-debug选项。 内存检查选项： --leak-check= [default: summary] 当 这个选项打开时，当客户程序结束时查找内存泄漏。内存泄漏意味着有用malloc分配内存块，但是没有用free释放，而且没有指针指向这块内存。这样的 内存块永远不能被程序释放，因为没有指针指向它们。如果设置为summary，Valgrind会报告有多少内存泄漏发生了。如果设置为full或 yes，Valgrind给出每一个独立的泄漏的详细信息。 --show-reachable= [default: no] 当 这个选项关闭时，内存泄漏检测器只显示没有指针指向的内存块，或者只能找到指向块中间的指针。当这个选项打开时，内存泄漏检测器还报告有指针指向的内存 块。这些块是最有可能出现内存泄漏的地方。你的程序可能，至少在原则上，应该在退出前释放这些内存块。这些有指针指向的内存块和没有指针指向的内存块，或 者只有内部指针指向的块，都可能产生内存泄漏，因为实际上没有一个指向块起始的指针可以拿来释放，即使你想去释放它。 --leak-resolution= [default: low] 在 做内存泄漏检查时，确定memcheck将怎么样考虑不同的栈是相同的情况。当设置为low时，只需要前两层栈匹配就认为是相同的情况；当设置为med， 必须要四层栈匹配，当设置为high时，所有层次的栈都必须匹配。对于hardcore内存泄漏检查，你很可能需要使用--leak- resolution=high和--num-callers=40或者更大的数字。注意这将产生巨量的信息，这就是为什么默认选项是四个调用者匹配和低 分辨率的匹配。注意--leak-resolution= 设置并不影响memcheck查找内存泄漏的能力。它只是改变了结果如何输出。 --freelist-vol= [default: 5000000] 当 客户程序使用free(C中)或者delete(C++)释放内存时，这些内存并不是马上就可以用来再分配的。这些内存将被标记为不可访问的，并被放到一 个已释放内存的队列中。这样做的目的是，使释放的内存再次被利用的点尽可能的晚。这有利于memcheck在内存块释放后这段重要的时间检查对块不合法的 访问。这个选项指定了队列所能容纳的内存总容量，以字节为单位。默认的值是5000000字节。增大这个数目会增加memcheck使用的内存，但同时也 增加了对已释放内存的非法使用的检测概率。 --workaround-gcc296-bugs= [default: no] 当 这个选项打开时，假定读写栈指针以下的一小段距离是gcc 2.96的bug，并且不报告为错误。距离默认为256字节。注意gcc 2.96是一些比较老的Linux发行版(RedHat 7.X)的默认编译器，所以你可能需要使用这个选项。如果不是必要请不要使用这个选项，它可能会使一些真正的错误溜掉。一个更好的解决办法是使用较新的， 修正了这个bug的gcc/g++版本。 --partial-loads-ok= [default: no] 控 制memcheck如何处理从地址读取时字长度，字对齐，因此哪些字节是可以寻址的，哪些是不可以寻址的。当设置为yes是，这样的读取并不抛出一个寻址 错误。而是从非法地址读取的V字节显示为未定义，访问合法地址仍然是像平常一样映射到内存。设置为no时，从部分错误的地址读取与从完全错误的地址读取同 样处理：抛出一个非法地址错误，结果的V字节显示为合法数据。注意这种代码行为是违背ISO C/C++标准，应该被认为是有问题的。如果可能，这种代码应该修正。这个选项应该只是做为一个最后考虑的方法。 --undef-value-errors= [default: yes] 控制memcheck是否检查未定义值的危险使用。当设为yes时，Memcheck的行为像Addrcheck, 一个轻量级的内存检查工具，是Valgrind的一个部分，它并不检查未定义值的错误。使用这个选项，如果你不希望看到未定义值错误。 CACHEGRIND选项： 手 动指定I1/D1/L2缓冲配置，大小是用字节表示的。这三个必须用逗号隔开，中间没有空格，例如： valgrind --tool=cachegrind --I1=65535,2,64你可以指定一个，两个或三个I1/D1/L2缓冲。如果没有手动指定，每个级别使用普通方式(通过CPUID指令得到缓冲 配置，如果失败，使用默认值)得到的配置。 --I1=,, 指定第一级指令缓冲的大小，关联度和行大小。 --D1=,, 指定第一级数据缓冲的大小，关联度和行大小。 --L2=,, 指定第二级缓冲的大小，关联度和行大小。 CALLGRIND选项： --heap= [default: yes] 当这个选项打开时，详细的追踪堆的使用情况。关闭这个选项时，massif.pid.txt或massif.pid.html将会非常的简短。 --heap-admin= [default: 8] 每个块使用的管理字节数。这只能使用一个平均的估计值，因为它可能变化。glibc使用的分配器每块需要4~15字节，依赖于各方面的因素。管理已经释放的块也需要空间，尽管massif不计算这些。 --stacks= [default: yes] 当打开时，在剖析信息中包
浙公网安备 33021202002483