收藏
Valgrind是一个动态二进制插桩（Dynamic Binary Instrumentation，DBI）框架，官网在：。
由于Valgrind对shadow value的支持，使得Valgrind这一DBI框架可以用来搭建heavyweight的动态二进制分析（Dynamic Binary Analysis，DBA）工具。正是由于这一特征，Valgrind框架下搭建出来的轻量级工具可能没有其它一些工具快，但是可以用来搭建一些PIN、DynamoRIO等DBI框架无法支持的重量级工具。
ps. 什么是Shadow value ，shadow value tools，有什么用
应用举例：
1）跟踪那些bit是没有定义的（未初始化或者由未定义的值计算而来），因此发现可能存在危险的使用
2）跟踪被污染的值（来自不被信任的来源，或由被污染的值计算而来）
3）跟踪保密的bit
4）跟踪每个值的类型，从而检测不恰当的使用等
5）跟踪哪些是数组指针
6）创建动态数据流图
在这些工具里，每个shadow value记录一个值的大概的历史。支持shadow value意味着需要对大量的操作进行精细的插桩。
Valgrind是一个GPL的软件，用于Linux（For x86, amd64 and ppc32）程序的内存调试和代码剖析。
你可以在它的环境中运行你的程序来监视内存的使用情况，比如C 语言中的malloc和free或者 C++中的new和 delete。使用Valgrind的工具包，你可以自动的检测许多内存管理和线程的bug，避免花费太多的时间在bug寻找上，使得你的程序更加稳固。
Valgrind的主要功能
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” 的竞争检测算法，并做了进一步改进，减少了报告错误的次数。
Massif
堆栈分析器，它能测量程序在堆栈中使用了多少内存，告诉我们堆块，堆管理块和栈的大小。Massif能帮助我们减少内存的使用，在带有虚拟内存的现代系统中，它还能够加速我们程序的运行，减少程序停留在交换区中的几率。
Valgrind 安装
1、 到下载最新版valgrind-3.4.1.tar.bz2
2、 解压安装包：tar –jxvf valgrind-3.4.1.tar.bz2
3、 解压后生成目录valgrind-3.4.1
4、 cd valgrind-3.4.1
5、 ./configure; make; make install
If you get an error that says there is an undefined reference to '__stack_chk_fail', either you need to reconfigure with gcc set todisable stack protection, or you have compiled part of the code with the stack protector and part without it, in which case you might have to enable it to finish compilation.You can enable/disable the stack protector in gcc in the following way:Disable: ./configure CC="gcc -fno-stack-protector"
Doing make clean first, will ensure that the whole platform gets compiled with the same flag
Enable: ./configure CC="gcc -fstack-protector"
1.检查内存错误：
例如我们原来有一个程序sec_infod，这是一个用gcc –g参数编译的程序，运行它需要：
#./a.out
如果我们想用valgrind的内存检测工具，我们就要用如下方法调用：
#valgrind --leak-check=full --show-reachable=yes --trace-children= yes ./a.out (2>logfile加上会好些，程序在执行期间stderr会有一些输出。提示比较多)
其中--leak-check=full 指的是完全检查内存泄漏，--show-reachable=yes是显示内存泄漏的地点，--trace-children=yes是跟入子进程。
如果您的程序是会正常退出的程序，那么当程序退出的时候valgrind自然会输出内存泄漏的信息。如果您的程序是个守护进程，那么也不要紧，我们只要在别的终端下杀死memcheck进程（因为valgrind默认使用memcheck工具，就是默认参数—tools=memcheck）：
#killall memcheck
这样我们的程序（./a.out）就被kill了
2,检查代码覆盖和性能瓶颈：
我们调用valgrind的工具执行程序：
#valgrind --tool=callgrind ./sec_infod
会在当前路径下生成callgrind.out.pid（当前生产的是callgrind.out.19689），如果我们想结束程序，可以：
#killall callgrind
然后我们看一下结果：
#callgrind_annotate --auto=yes callgrind.out.19689 >log
#vim log
3.Valgrind使用参数
--log-fd=N 默认情况下，输出信息是到标准错误stderr，也可以通过—log-fd=8，输出到描述符为8的文件
--log-file=filename将输出的信息写入到filename.PID的文件里，PID是运行程序的进行ID。可以通过--log-file exactly=filename指定就输出到filename文件。
--log-file-qualifier=,取得环境变量的值来做为输出信息的文件名。如—log-file-qualifier=$FILENAME。
--log-socket=IP:PORT 也可以把输出信息发送到网络中指定的IP:PORT去
--error-limit=no 对错误报告的个数据进行限制，默认情况不做限制
--tool= [default: memcheck]
--tool=memcheck：要求用memcheck这个工具对程序进行分析
--leak-ckeck=yes 要求对leak给出详细信息
--trace-children= [default: no]跟踪到子进程里去，默认请况不跟踪
--xml= [default: no]将信息以xml格式输出，只有memcheck可用
--gen-suppressions= [default: no]如果为yes，valgrind会在每发现一个错误便停下让用户做选择是继续还是退出
更多选项请参看： 可以把一些默认选项编辑在 ~/.valgrindrc文件里。
这里使用valgrind的memcheck和callgrind两个工具的用法，其实valgrind还有几个工具：“cachegrind”,用于检查缓存使用的；“helgrind”用于检测多线程竞争资源的，等等。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/fisher_jiang/archive/2009/06/18/4280241.aspx
