为什么用valgrind跑kill 程序名会被kill掉

用valgrind 检查程序,错误代码看不懂,急。。。。_百度知道1028人阅读
辅助工具(9)
在此记录常用方法,省的我老是忘记 =.=!!。&valgrind --leak-check=full --tool=memcheck 程序运行命令
&&&&&&&Valgrind是运行在Linux上一套基于仿真技术的程序调试和分析工具,是公认的最接近Purify的产品,它包含一个内核——一个软件合成的CPU,和一系列的小工具,每个工具都可以完成一项任务——调试,分析,或测试等。Valgrind可以检测内存泄漏和内存越界,还可以分析cache的使用等,灵活轻巧而又强大。&&&
&&&&&&&&Valgrind的最新版是3.2.3,该版本包含下列工具:
、Memcheck:
是一个内存错误探测器。检查程序中的内存问题,如泄漏、越界、非法指针等。它能够纠正你的程序中的错误,特别是用C和C++编写的程序。
、Callgrind:
是一个call-graphgenerating cache profiler。检测程序代码覆盖,以及分析程序性能。它的功能与Cachegrind有些重复,但也收集了一些Cachegrind没有的信息。
、Cachegrind:
是一个cache和分支预测分析器(a cache and branch-prediction profiler)。分析CPU的cache命中率、丢失率,用于进行代码优化。它帮助你使得你的程序跑的更快。
、Helgrind:
是一个线程错误探测器。用于检查多线程程序的竞态条件。它帮助你纠正你的多线程程序。
、Massif:
是一个堆分析器。堆栈分析器,指示程序中使用了多少堆内存等信息。它帮助你使得你的程序使用更少的内存。
、Lackey:
是一个示例工具,它主要用来说明一些instrumentation的基本功能。
、Nulgrind:
是最小化的Valgrind工具,它不做任何分析或instrumentation,仅用于testing目的。
也是一个线程错误探测器。它跟Helgrind是相似的,但使用不同的分析技术,所以可能能够发现不同的问题。
是一个不同类型的堆分析器。它帮助你了解块生命周期,块利用,和布局失效(layout inefficiencies)。
、SGcheck:
是一个实验性的数据,它能够探测stack和全局数组的越界。它的功能是Memcheck的补充,SGcheck能找到Memcheck不能找到的错误,反之也是如此。
是一个实验性的SimPoint基本的块向量产生器。它用于计算机体系结构研究和开发。
、Memcheck
最常用的工具,用来检测程序中出现的内存问题,所有对内存的读写都会被检测到,一切对malloc、free、new、delete的调用都会被捕获。所以,它能检测以下问题:
&&&&&&&1、对未初始化内存的使用;
&&&&&&&2、读/写释放后的内存块;
&&&&&&&3、读/写超出malloc分配的内存块(读/写内存越界);
&&&&&&&4、读/写不适当的栈中内存块;
&&&&&&&5、内存泄漏,指向一块内存的指针永远丢失;
&&&&&&&6、不正确的malloc/new/new[]和free/delete/delete[]匹配;
&&&&&&&7、memcpy()相关函数中的dst和src指针重叠。
这些问题往往是C/C++程序员最头疼的问题,Memcheck能在这里帮上大忙。
调用选项:
--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的一个部分),它并不检查未定义值的错误。如果你不希望看到未定义值错误,可以使用这个选项。
、Callgrind
&&&&& 和gprof类似的分析工具,但它对程序的运行观察更是入微,能给我们提供更多的信息。和gprof不同,它不需要在编译源代码时附加特殊选项,但加上调试选项是推荐的。Callgrind收集程序运行时的一些数据,建立函数调用关系图,还可以有选择地进行cache模拟。在运行结束时,它会把分析数据写入一个文件。callgrind_annotate可以把这个文件的内容转化成可读的形式。
Callgrind收集程序运行时的一些数据,函数调用关系等信息,还可以有选择地进行cache模拟。在运行结束时,它会把分析数据写入一个文件。callgrind_annotate可以把这个文件的内容转化成可读的形式。
$valgrind --tool=callgrind ./sec_infod
会在当前目录下生成callgrind.out.[pid],如果我们想结束程序, 可以
$killall callgrind
然后我们可以用
$callgrind_annotate --auto=yescallgrind.out.[pid] & log
调用选项:
--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。
、Cachegrind
cachegrind是一个cache剖析器,它模拟CPU中的一级缓存I1(一级指令缓存,Instruction Cache,I-Cache),D1(1级数据缓存,Data Cache,D-Cache)和二级缓存L2 cache,大小用字节表示。能够精确地指出程序中cache的丢失和命中。如果需要,它还能够为我们提供(打印出)cache丢失次数,内存引用和发生cache未命中的每一行代码,每个函数,每个模块,整个程序产生的指令数和整个程序的摘要。如果你要求更细致的信息,它可以打印出每一行机器码的未命中次数。这对优化程序有很大的帮助。在x86和amd64上,cachegrind通过CPUID自动探测机器的cache配置,所以在多数情况下它不再需要更多的配置信息了。
你可以指定一个,两个或三个I1/D1/L2缓冲。如果没有手动指定,每个级别使用普通方式(通过CPUID指令得到缓冲配置,如果失败,使用默认值)得到的配置。
调用选项:
--I1=&size&,&associativity&,&linesize&
指定第一级指令缓冲的大小,关联度和行大小。
--D1=&size&,&associativity&,&linesize&
指定第一级数据缓冲的大小,关联度和行大小。
--L2=&size&,&associativity&,&linesize&
指定第二级缓冲的大小,关联度和行大小。
这三个必须用逗号隔开,中间没有空格,例如:valgrind --tool=cachegrind--I1=
、Helgrind
&&&&&&&&它主要用来检查多线程程序中出现的竞争问题。Helgrind寻找内存中被多个线程访问,而又没有一贯加锁的区域,这些区域往往是线程之间失去同步的地方,而且会导致难以发掘的错误。Helgrind实现了名为“Eraser”的竞争检测算法,并做了进一步改进,减少了报告错误的次数。不过,Helgrind仍然处于实验阶段。
调用选项:
--private-stacks=&yes|no&[default: no]
假定线程栈是私有的。
--show-last-access=&yes|some|no&[default: no]
显示最后一次字访问出错的位置。
堆栈分析器,它能测量程序在堆栈中使用了多少内存,告诉我们堆块,堆管理块和栈的大小。Massif能帮助我们减少内存的使用,在带有虚拟内存的现代系统中,它还能够加速我们程序的运行,减少程序停留在交换区中的几率。
Massif对内存的分配和释放做profile。程序开发者通过它可以深入了解程序的内存使用行为,从而对内存使用进行优化。这个功能对C++尤其有用,因为C++有很多隐藏的内存分配和释放。
lackey是一个示例程序,以其为模版可以创建你自己的工具。在程序结束后,它打印出一些基本的关于程序执行统计数据。
LACKEY选项:
--fnname=&name& [default:_dl_runtime_resolve()]
对&name&函数计数。
--detailed-counts=&no|yes&[default: no]
对读取,存储和alu操作计数。
、Nulgrind:
是最小化的Valgrind工具,它不做任何分析或instrumentation,仅用于testing目的。
也是一个线程错误探测器。它跟Helgrind是相似的,但使用不同的分析技术,所以可能能够发现不同的问题。
是一个不同类型的堆分析器。它帮助你了解块生命周期,块利用,和布局失效(layout inefficiencies)。
、SGcheck:
是一个实验性的数据,它能够探测stack和全局数组的越界。它的功能是Memcheck的补充,SGcheck能找到Memcheck不能找到的错误,反之也是如此。
是一个实验性的SimPoint基本的块向量产生器。它用于计算机体系结构研究和开发。
、基本使用方法
Valgrind使用起来非常简单,你甚至不需要重新编译你的程序就可以用它。当然如果要达到最好的效果,获得最准确的信息,还是需要按要求重新编译一下的。比如在使用memcheck的时候,最好关闭优化选项。
&&&&&&&valgrind命令的格式如下:
valgrind programargs
这种情况下,将在Valgrind使用Memcheck运行程序program(带有参数args)。内存检查执行一系列的内存检查功能,包括检测访问未初始化的内存,已经分配内存的错误使用(两次释放,释放后再访问,等等)并检查内存泄漏。
还可以使用--tool指定使用其它工具。例如:valgrind --tool=toolname program args。其中,可以适用的工具有:cachegrind、callgrind、helgrind、lackey、massif、memcheck、none(没有任何功能。它一般用于Valgrind的调试和基准测试)。
具体总结如下:
valgrind&[valgrind-options] your-prog [your-progoptions]
、一些常用的基本选项如下(这些选项对所有工具都有效):
显示帮助信息。
--help-debug
和--help相同,并且还能显示通常只有Valgrind的开发人员使用的调试选项。
显示valgrind内核的版本,每个工具都有各自的版本。这是一种保证工具只在它们可以运行的内核上工作的一种设置。这样可以减少在工具和内核之间版本兼容性导致奇怪问题的概率。
-q --quiet
安静地运行,只打印错误信息。
-v --verbose
打印更详细的信息。在各个方面显示你的程序的额外信息,例如:共享对象加载,使用的重置,执行引擎和工具的进程,异常行为的警告信息。重复这个标记可以增加详细的级别
调试Valgrind自身发出的信息。通常只有Valgrind开发人员对此感兴趣。重复这个标记可以产生更详细的输出。如果你希望发送一个bug报告,通过-v -v -d -d生成的输出会使你的报告更加有效。
--tool=&toolname& [default: memcheck]
最常用的选项。运行valgrind中名为toolname的工具。如果省略工具名,默认运行memcheck。
--db-attach=&yes|no& [default: no]
绑定到调试器上,便于调试错误。
--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将会在每个错误显示之后自动暂停并且打印下面这一行:
---- Printsuppression ? --- [Return/N/n/Y/y/C/c] ----
这个提示的行为和--db-attach选项(见下面)相同。
如果选择是,Valgrind会打印出一个错误的禁止条目,你可以把它剪切然后粘帖到一个文件,如果不希望在将来再看到这个错误信息。
当设置为all时,Valgrind会对每一个错误打印一条禁止条目,而不向用户询问。
这个选项对C++程序非常有用,它打印出编译器调整过的名字。
注意打印出来的禁止条目是尽可能的特定的。如果需要把类似的条目归纳起来,比如在函数名中添加通配符。并且,有些时候两个不同的错误也会产生同样的禁止条目,这时Valgrind就会输出禁止条目不止一次,但是在禁止条目的文件中只需要一份拷贝(但是如果多于一份也不会引起什么问题)。并且,禁止条目的名字像&在这儿输入一个禁止条目的名字&;名字并不是很重要,它只是和-v选项一起使用打印出所有使用的禁止条目记录。
--db-attach=&yes|no& [default: no]
当这个选项打开时,Valgrind将会在每次打印错误时暂停并打出如下一行:
---- Attach todebugger ? --- [Return/N/n/Y/y/C/c] ----
按下回车,或者N、回车,n、回车,Valgrind不会对这个错误启动调试器。
按下Y、回车,或者y、回车,Valgrind会启动调试器并设定在程序运行的这个点。当调试结束时,退出,程序会继续运行。在调试器内部尝试继续运行程序,将不会生效。
按下C、回车,或者c、回车,Valgrind不会启动一个调试器,并且不会再次询问。
注意:--db-attach=yes与--trace-children=yes有冲突。你不能同时使用它们。Valgrind在这种情况下不能启动。
--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选项运行极少影响速度,因为对大多数程序,非常少的代码被添加到栈中)。
、检测内存泄漏
&&&&示例代码如下:
#include &stdlib.h&
#include &stdio.h&
int main(void)
&&&&&&&char *
&&&&&&&ptr = (char*)malloc(10);
&&&&&&&return 0;
保存为memleak.c并编译,然后用valgrind检测。
$ gcc -o memleak memleak.c
(valgrind和purify最大的不同在于:valgrind只接管程序执行的过程,编译时不需要valgrind干预,而purify会干预程序编译过程)
$&valgrind&--tool=memcheck./memleak
我们得到如下错误信息:
[konten@tencent test_valgrind]$valgrind&./memleak
==29646== Memcheck, a memory error detector.
==29646== Copyright (C) , and GNU GPL'd, byJulian Seward et al.
==29646== Using LibVEX rev 1732, a library for dynamicbinary translation.
==29646== Copyright (C) , and GNU GPL'd, byOpenWorks LLP.
==29646== Using valgrind-3.2.3, a dynamic binaryinstrumentation framework.
==29646== Copyright (C) , and GNU GPL'd, byJulian Seward et al.
==29646== For more details, rerun with: -v
==29646== ERROR SUMMARY: 0 errors from 0contexts (suppressed: 15 from 1)
==29646== malloc/free: in use at exit: 10bytes in 1 blocks.&&&//指示在程序退出时,还有多少内存没有释放。
==29646== malloc/free: 1 allocs, 0 frees,10 bytes allocated.&//&指示该执行过程malloc和free调用的次数。
==29646== For counts of detected errors,rerun with: -v&//&提示如果要更详细的信息,用-v选项。
==29646== searching for pointers to 1not-freed blocks.
==29646== checked 56,164 bytes.
==29646== LEAK SUMMARY:
==29646==&&&&definitelylost: 10 bytes in 1 blocks.
==29646==&&&&&&possiblylost: 0 bytes in 0 blocks.
==29646==&&&&stillreachable: 0 bytes in 0 blocks.
==29646==&&&&&&&&&suppressed:0 bytes in 0 blocks.
==29646== Rerun with --leak-check=full tosee details of leaked memory.
[konten@tencenttest_valgrind]$
以上结果中,红色的是手工添加的说明信息,其他是valgrind的输出。可以看到,如果我们仅仅用默认方式执行,valgrind只报告内存泄漏,但没有显示具体代码中泄漏的地方。
因此我们需要使用&“--leak-check=full”选项启动&valgrind,我们再执行一次:
[konten@tencent test_valgrind]$ valgrind--leak-check=full ./memleak
==29661== Memcheck, a memory error detector.
==29661== Copyright (C) , and GNU GPL'd, byJulian Seward et al.
==29661== Using LibVEX rev 1732, a library for dynamicbinary translation.
==29661== Copyright (C) , and GNU GPL'd, byOpenWorks LLP.
==29661== Using valgrind-3.2.3, a dynamic binaryinstrumentation framework.
==29661== Copyright (C) , and GNU GPL'd, byJulian Seward et al.
==29661== For more details, rerun with: -v
==29661== ERROR SUMMARY: 0 errors from 0 contexts(suppressed: 15 from 1)
==29661== malloc/free: in use at exit: 10 bytes in 1blocks.
==29661== malloc/free: 1 allocs, 0 frees, 10 bytesallocated.
==29661== For counts of detected errors, rerun with:-v
==29661== searching for pointers to 1 not-freedblocks.
==29661== checked 56,164 bytes.
==29661== 10 bytes in 1 blocks aredefinitely lost in loss record 1 of 1
==29661==&&&&at0x401A846: malloc (vg_replace_malloc.c:149)
==29661==&&&&by0x804835D: main (memleak.c:6)
==29661== LEAK SUMMARY:
==29661==&&&&definitely lost: 10bytes in 1 blocks.
==29661==&&&&&&possiblylost: 0 bytes in 0 blocks.
==29661==&&&&still reachable: 0bytes in 0 blocks.
==29661==&&&&&&&&&suppressed:0 bytes in 0 blocks.
[konten@tencenttest_valgrind]$
&&&&&&&&和上次的执行结果基本相同,只是多了上面蓝色的部分,指明了代码中出现泄漏的具体位置。
&&&&&&&&以上就是用valgrind检查内存泄漏的方法,用到的例子比较简单,复杂的代码最后结果也都一样。
、其他内存问题
我们下面的例子中包括常见的几类内存问题:堆中的内存越界、踩内存、栈中的内存越界、非法指针使用、重复free。
#include &stdlib.h&
#include &stdio.h&
int main(void)
&&&&char *ptr = malloc(10);
&&&&ptr[12] = 'a'; //&内存越界
&&&&memcpy(ptr +1, ptr, 5);//&踩内存
&&&&char a[10];
&&&&a[12] = 'i';&//&数组越界
free(ptr);&//&重复释放
&&&&free(ptr);
&&&&char *p1;
&&&&*p1 = '1';&//&非法指针
&&&&return 0;
编译:&gcc -oinvalidptr invalidptr.c -g
执行:valgrind--leak-check=full ./invalidptr
结果如下:
[konten@tencent test_valgrind]$ valgrind--leak-check=full ./invalidptr
==29776== Memcheck, a memory error detector.
==29776== Copyright (C) , and GNU GPL'd, byJulian Seward et al.
==29776== Using LibVEX rev 1732, a library for dynamicbinary translation.
==29776== Copyright (C) , and GNU GPL'd, byOpenWorks LLP.
==29776== Using valgrind-3.2.3, a dynamic binaryinstrumentation framework.
==29776== Copyright (C) , and GNU GPL'd, byJulian Seward et al.
==29776== For more details, rerun with: -v
==29776== Invalid write of size 1&//堆内存越界被查出来
==29776==&&&&at 0x80483D2: main(invalidptr.c:7)
==29776==&Address 0x4159034 is 2 bytes after ablock of size 10 alloc'd
==29776==&&&&at 0x401A846: malloc(vg_replace_malloc.c:149)
==29776==&&&&by 0x80483C5: main(invalidptr.c:6)
==29776== Source and destination overlap inmemcpy(0xx)&//踩内存
==29776==&&&&at 0x401C96D: memcpy(mc_replace_strmem.c:116)
==29776==&&&&by 0x80483E6: main(invalidptr.c:9)
==29776== Invalid free() / delete / delete[]&//重复释放
==29776==&&&&at 0x401B3FB: free(vg_replace_malloc.c:233)
==29776==&&&&by 0x8048406: main(invalidptr.c:16)
==29776==&Address 0x4159028 is 0 bytes inside ablock of size 10 free'd
==29776==&&&&at 0x401B3FB: free(vg_replace_malloc.c:233)
==29776==&&&&by 0x80483F8: main(invalidptr.c:15)
==29776== Use of uninitialised value of size 4
==29776==&&&&at 0x804840D: main(invalidptr.c:19)
==29776==&//非法指针,导致coredump
==29776== Process terminating with default action ofsignal 11 (SIGSEGV): dumping core
==29776==&Bad permissions for mapped region ataddress 0x80482AD
==29776==&&&&at 0x804840D: main(invalidptr.c:19)
==29776== ERROR SUMMARY: 4 errors from 4 contexts(suppressed: 15 from 1)
==29776== malloc/free: in use at exit: 0 bytes in 0blocks.
==29776== malloc/free: 1 allocs, 2 frees, 10 bytesallocated.
==29776== For counts of detected errors, rerun with:-v
==29776== All heap blocks were freed -- no leaks arepossible.
Segmentation fault
[konten@tencent test_valgrind]$
&&&&&&&&从上面的结果看出,除了栈内存越界外,其他常见的内存问题都可以用valgrind简单的查出来。
、下载源代码
下载地址http://valgrind.org/downloads/current.html#current&,截止目前为止,最新版本是3.2.3
、编译,在源代码目录下执行:
&&&&&&&&&&&&&&./configure--prefix=[你自己的安装目录]
&&&&&&&&&&&&&&makeinstall
&&&&&&&便好了。
、配置缺省选项
&&&&&&&&&&&&&&valgrind提供3种方式用于设置缺省选项:
a、~/.valgrindrc文件;
b、环境变量$VALGRIND_OPTS;
c、当前目录下的.valgrindrc文件;
&&&&&&&&&&&&& 优先顺序为&a、b、c
&&&&&&&&&&&&& .valgrindrc的格式为:
&&&&&&&&&&&--ToolName:OptionName=OptionVal
&&&&&&&如:
&&&&&&&&&&&&&&&--memcheck:leak-check=yes
&&&&&&&&&&&&&& --memcheck:show-reachable=yes
参考知识库
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
访问:208453次
积分:3271
积分:3271
排名:第7362名
原创:108篇
转载:88篇
评论:58条
(1)(1)(2)(2)(1)(4)(5)(7)(3)(4)(3)(7)(6)(20)(2)(2)(1)(1)(1)(3)(1)(1)(4)(8)(12)(64)(23)(8)

我要回帖

更多关于 kill 程序名 的文章

 

随机推荐