参考:http://www.cnblogs.com/sunyubo/archive/2010/05/05/2282170.html

几乎是照抄参考过来的,只不过后面自己调试一下代码。

 

这里主要介绍Valgrind的一些简单用法更多详细的使用方法可以访问valgrind的主页:http://www.valgrind.org

Valgrind是Julian Seward的作品。Valgrind是运行在Linux上一套基于仿真技术的程序调试和分析工具,它包含一个内核,一个软件合成的CPU,和一系列的小工具。

每个工具都可以完成一项任务—调试分析或测试等。

Valgrind可以检测内存泄漏和内存违例。还可以分析cache的使用,灵活又强大,值得入手。

 

一、Valgrind概述

它主要有下列几个工具。

1.Memcheck

最常用的,用来检测程序中出现的内存问题,所有对内存的读写都会被检测到,一切对malloc和free的调用都会被捕获,所以它能检测下列问题:

1)对为初始化内存的使用

2)读/写释放后的内存块

3)读/写超出malloc分配的内存块

4)读/写不适当的栈中的内存块

5)内存泄漏,指向一块内存的指针永远丢失

6)不正确的malloc/free或new/delete匹配

7)memcpy相关函数中的dst和src指针重叠

 

2.Callgrind

和gprof类似的分析工具,但它对程序的运行观察更细致入微,能给我们提供更多的信息。和gprof不同,它不需要在编译源代码时添加附加特殊选项,但加上调试选项是推荐的。

Callgrind收集程序运行时的一些数据,建立函数调用关系图,还可以有选择的进行cache模拟。在运行结束时,它会把分析数据写入一个文件,callgrind_annotate可以把这个文件的内容转化成可读的形式。

 

3.Cachegrind

Cache分析器,它模拟CPU中的一级缓存I1,DI和二级缓存,能够精确的指出程序中cache的丢失和命中。

如果需要,它还能为我们提供cache丢失次数,内存引用次数,以及每行代码,每个函数,每个模块整个程序产生的指令数,这对优化程序有很大的帮助。

 

4.Helgrind

用来检测多线程程序中出现的竞争问题。Helgrind寻找内存中内对个线程访问,而又没有一贯加锁的区域。这些区域往往是线程之间失去同步的情况,而且会导致难以发掘的错误。

Helgrind实现了名为“Eraser”的竞争检测算法,并做了进一步改进,减少了报告错误的次数。不过Helgrinf仍然处于实验阶段。

 

5.Massif

堆栈分析器,它能测量程序在堆栈中使用了多少内存,告诉我们堆块,堆管理块和栈的大小。Massif能帮助我们减少内存的使用,在代用虚拟内存的现代系统中,它还能加速我们程序的运行,减少程序停留在交换区中的几率。

 

此外,lackey和nulgrind也会提供。Lackey是小型工具,很少用到;Nulgrind只是为开发者展示如何创建一个工具。

 

二、使用Valgrind

先安装,我的服务器上已经安装好了,不知道是不是所有的linux都自带这个东西。

  

命令格式如下:

valgrind [valgtind-options] your-prog [your-prog options]

比如:

-h  显示帮助信息

–version 显示内核版本信息(我也不知道为啥不是-v)

-q 安静的运行,只打印错误信息

-tool=[default:memcheck]  最常用的选项,后面接工具名。如果省略工具名,默认运行memcheck

 

比如下面的程序:

#include<stdio.h>

#include<stdlib.h>

void fun()

{

         int *x = malloc(10 * sizeof(int));

         x[10] = 0;

}

int main()

{

         int i = 99;

         fun();

         printf("i = %d\n", i);

         return 0;

}

存在两个问题:

1)没有free掉申请的资源

2)fun函数里面越界了,x[10]是非法的

 

下面演示如何使用valgrind中的memcheck:

调用时还可以加上tool:  $valgrind –tool=memcheck ./malloc

 

==28308== 中的28308表示程序运行时的进程号。

Invalid write of size 4:表示非法写入,下面是告诉我们错误发生的位置,在main中调用的fun函数。

HEAP SUMMARY:说明了堆的情况,可以看到申请了40个字节,后面说有1个申请,0个被free。

LEAK SUMMARY:也是说的堆的泄漏情况,明显丢失的有40个字节。

如果main中的i没有赋值,这里还会有一些其他的错误,具体可以自己试一下。这个需要运用到实际项目中才能更加理解。

 

下面就是i没有赋值的错误信息截取了部分:

 

 

下面介绍一些其他用法(我也是照着参考学的,具体如何用到实际项目中还需要自己领悟):

测试下面时,main函数中的i我改为了没有赋值:

1.一旦出现错误,valgrind会自动启动调试器(一般是gdb):

 

 

2.下面来试试callgrind:

 

可以看到生成了一个文件(绿色框框)。当callgrind运行你的程序时,还可以使用callgrind_control来观察程序的执行,而且不会干扰它的运行:

下面显示如何查看详细信息:

 

 

3.再来试试cachegrind:

 

上面是指令缓存,I1和L2i缓存的访问信息,包括总的访问次数,丢失次数,丢失率。

中间是数据缓存,D1和L2d缓存的访问相关信息。

下面是L2缓存单独的信息。

也有一个输出文件,cachegrind.out.25843,可以用cg_annotate 来查看。显示出详细的列表。

 

4.missif的使用

跟cachegrind类似,只不过生成的文件不一样,生成的是massif.pid.ps的PostScript文件,里面只有一副描述堆栈使用情况的彩图。

 

版权声明:本文为xcywt原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/xcywt/p/8530389.html