使用valgrind进行内存分析

简介

官网地址:http://valgrind.org
主要提供以下工具：

Memcheck 是一个内存错误的检测工具，帮助你的程序，尤其是c/c++程序出现更少内存的问题。
Cachegrind 是一个缓存和分支预测探查工具，帮助你的程序运行的更快。
Callgrind 也是一个和缓存相关的调用图工具，和Cachegrind有一部分重叠，但也生成一些Cachegrind不提供的信息。
Helgrind 是一个线程错误的检测工具，在多线程场景下能派上用场。
DRD 也是一个线程错误的检测工具，与Helgrind功能一样，但是使用了不同的分析技术，可能会发现不同的问题。
Massif 是一个堆分析工具，帮助程序使用更少的内存。
DHAT 是不同与Massif的堆分析工具，帮助你理解块的生命周期, 块的利用率, 以及layout的低效。
SGcheck 是一个实验性的工具，帮助检测栈的超支和全局数组。是Memcheck的功能方面的补充：可以检测出Memcheck无法发现的问题，反之亦然。
BBV 是一个实验SimPoint基本块向量生成器。对于进行计算机体系结构研究和开发的人来说，这是有用的。

这里记录的只是Memcheck的使用，其他的使用可以参考上述的官网的网址。

ubuntu下的安装

sudo apt-get install valgrind

使用方法

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

例如,对ls -l进行分析:

valgrind –tool=memcheck ls -l

valgrind的默认工具就是memcheck，所以使用memcheck工具时可以省略–tool参数

注意事项:

1、valgrind工具会减慢程序的运行速度
2、程序编译时需要开启-g，帮助valgrind可以更精准的定位到错误
3、程序编译时最好关闭优化，否则可能产生不正确的未初始化错误信息，以及遗漏未初始化错误。
4、程序编译时最好使用-Wall，帮助valgrind在高优化等级的程序中精准识别一些甚至是全部的问题

具体使用说明

Valgrind会记录下一些注释，文本流，具体的错误报告以及其他的重要的事件。类似与以下的格式:

==12345== some-message-from-Valgrind

12345代表进程Id,这个格式方便区分程序输出和Valgrind的注释输出，以及区分多个进程的输出。Valgrind只会输出最重要的信息，如果需要一些次要的信息，可以使用-v参数。

你可以使用三种方式去导出这些错误

1、默认情况:会直接在控制台打印出来
2、使用文件记录，这个时候需要使用参数–log-file=filename,filename代表存储的文件名
3、通过socket发送:使用参数–log-socket=192.168.0.1:12345，不加端口号会使用默认的1500端口，Valgrind提供了一个叫Valgrind-listener的工具去监听这个网络流。

读懂memcheck工具产生的错误信息

1.非法读/非法写的错误(Illegal read/Illegal write errors)

例如:

Invalid read of size 4
at 0x40F6BBCC: (within /usr/lib/libpng.so.2.1.0.9)
by 0x40F6B804: (within /usr/lib/libpng.so.2.1.0.9)
by 0x40B07FF4: read_png_image(QImageIO *) (kernel/qpngio.cpp:326)
by 0x40AC751B: QImageIO::read() (kernel/qimage.cpp:3621)
Address 0xBFFFF0E0 is not stack’d, malloc’d or free’d

出现这个错误是因为程序读或写了Valgrind认为不应该读写的内存区域

2.使用了为初始化的值

例如:

Conditional jump or move depends on uninitialised value(s)
at 0x402DFA94: _IO_vfprintf (_itoa.h:49)
by 0x402E8476: _IO_printf (printf.c:36)
by 0x8048472: main (tests/manuel1.c:8)
这样一段错误可能就是由以下的代码产生

int main()
{
int x;
printf ("x = %d\n", x);
}

Valgrind会跟踪变量x,直到x被使用时才会报错。在这里x被传入了printf,进而进入_IO_printf，但是这些都不会报错，只有当x被传递到_IO_vfprintf,_IO_vfprintf开始检查x是否可以被转换为ASCII码时才报错。

未初始化值一般有两种情况:

• 1、局部变量没有被初始化，就像上面一样。
• 2、The contents of heap blocks (allocated with malloc, new, or a similar function) before you (or a constructor) write something there.

为了找到未初始化变量一开始的位置，可以使用–track-origins=yes参数。当然这会减慢Valgrind的使用速度。

3.在系统调用中使用了未初始化或者不可寻址的值

Valgrind会检查所有系统调用的参数，一般有以下3类:

• 1、检查所有直接调用的参数，即使已经初始化了。
• 2、如果系统调用需要你的程序申请的缓冲区，Valgrind会检查所有的缓冲区内容，看它是否可寻址，内容是否初始化了。
• 3、如果系统调用需要写入用户提供的缓冲，Valgrind会检查是否可寻址。

下面是两个使用了无效参数的系统调用的例子:

#include
#include
int main( void )
{
char* arr = malloc(10);
int* arr2 = malloc(sizeof(int));
write( 1 /* stdout */, arr, 10 );
exit(arr2[0]);
}

得到这样的错误信息:

Syscall param write(buf) points to uninitialised byte(s)
at 0x25A48723: __write_nocancel (in /lib/tls/libc-2.3.3.so)
by 0x259AFAD3: __libc_start_main (in /lib/tls/libc-2.3.3.so)
by 0x8048348: (within /auto/homes/njn25/grind/head4/a.out)
Address 0x25AB8028 is 0 bytes inside a block of size 10 alloc’d
at 0x259852B0: malloc (vg_replace_malloc.c:130)
by 0x80483F1: main (a.c:5)

Syscall param exit(error_code) contains uninitialised byte(s)
at 0x25A21B44: __GI__exit (in /lib/tls/libc-2.3.3.so)
by 0x8048426: main (a.c:8)

write（a）和exit（b）都是错误的，a从堆中向标准输出中写入了未初始化的arr。b向exit传递了为初始化的值。注意a的错误在于arr指向的内存区域，而b的错误直接是arr2[0]。

4.非法的释放(Illegal frees)

例如:

Invalid free()
at 0x4004FFDF: free (vg_clientmalloc.c:577)
by 0x80484C7: main (tests/doublefree.c:10)
Address 0x3807F7B4 is 0 bytes inside a block of size 177 free’d
at 0x4004FFDF: free (vg_clientmalloc.c:577)
by 0x80484C7: main (tests/doublefree.c:10)

这个例子中，一块区域被free了两次，所以出现Illegal frees的错误。

5.使用不合适的释放函数去释放堆区域的内存

例如:

Mismatched free() / delete / delete []
at 0x40043249: free (vg_clientfuncs.c:171)
by 0x4102BB4E: QGArray::~QGArray(void) (tools/qgarray.cpp:149)
by 0x4C261C41: PptDoc::~PptDoc(void) (include/qmemarray.h:60)
by 0x4C261F0E: PptXml::~PptXml(void) (pptxml.cc:44)
Address 0x4BB292A8 is 0 bytes inside a block of size 64 alloc’d
at 0x4004318C: operator new[](unsigned int) (vg_clientfuncs.c:152)
by 0x4C21BC15: KLaola::readSBStream(int) const (klaola.cc:314)
by 0x4C21C155: KLaola::stream(KLaola::OLENode const *) (klaola.cc:416)
by 0x4C21788F: OLEFilter::convert(QCString const &) (olefilter.cc:272)

这个错误是因为使用new[]开辟内存空间，却使用了free去释放内存。
使用malloc, calloc, realloc, valloc or memalign,必须使用free释放内存。
使用new, 必须使用delete释放内存。
使用new[],必须使用delete[]释放内存。

6.源内存区域和目标内存区域重叠

memcpy, strcpy, strncpy, strcat, strncat这些函数可以从源内存区域复制内容到目标内存区域。这两块区域是不可以重叠的。POSIX标准规定这种行为是未定义的。
例如

==27492== Source and destination overlap in memcpy(0xbffff294, 0xbffff280, 21)
==27492== at 0x40026CDC: memcpy (mc_replace_strmem.c:71)
==27492== by 0x804865A: main (overlap.c:40)

7.Fishy argument values

所以的内存分配函数都指定了分配的内存大小，这个大小必定为正数，或者一般情况下不会极度的大。例如在64位的机器上，不会申请分配2^63大小的内存。这种为负数的或者过于大的参数被成为Fishy argument。
例如:

==32233== Argument ‘size’ of function malloc has a fishy (possibly negative) value: -3
==32233== at 0x4C2CFA7: malloc (vg_replace_malloc.c:298)
==32233== by 0x400555: foo (fishy.c:15)
==32233== by 0x400583: main (fishy.c:23)

8.内存泄漏检测

Valgrind会跟踪所有由malloc或new申请的内存，所以当程序退出时,Valgrind知道哪些内存没有被主动释放。
如果–leak-check参数设置得当，对于每一个未被释放的内存块，Valgrind判断从root-set中的指针是否能到达这些内存块。root-set包含（a）普通的所有线程使用的寄存器，（b）初始化的, 对齐的, 指针大小的数据块，包括栈。一个数据块有两种方式可到达，第一种是“start-pointer”，即指针在数据块的开头;第二种是“interior-pointer”，即指针在数据块的中间。“interior-pointer”有多种方式出现：

• 指针一开始是“start-pointer”，被程序有意或无意的移动到中间。

• 可能只是巧合。

• std::string中的char的指针。

• 有些代码分配块内存，使用前8个去存储作为64位的数。例如sqlite3MemMalloc就是这样做的。

• 可能是一个c++对象（具有析构函数）数组的指针，由new[]来分配内存。这种情况下，有些编译器存储一个“magic cookie”，包含数组长度存储在分配的块开头。

• 可能是一个多重继承产生的c++对象的内部部分的指针。

在使用了启发式（heuristics）的情况下，stdstring, length64, newarray and multipleinheritance情况下的“interior-pointer”会被当成“start-pointer”对待。

考虑下面这九种情况：

Pointer chain AAA Leak Case BBB Leak Case

---

(1) RRR ————> BBB DR
(2) RRR —> AAA —> BBB DR IR
(3) RRR BBB DL
(4) RRR AAA —> BBB DL IL
(5) RRR ——?—–> BBB (y)DR, (n)DL
(6) RRR —> AAA -?-> BBB DR (y)IR, (n)DL
(7) RRR -?-> AAA —> BBB (y)DR, (n)DL (y)IR, (n)IL
(8) RRR -?-> AAA -?-> BBB (y)DR, (n)DL (y,y)IR, (n,y)IL, (_,n)DL
(9) RRR AAA -?-> BBB DL (y)IL, (n)DL

Pointer chain legend:
– RRR: a root set node or DR block(一个root set或者直接可达的块）
– AAA, BBB: heap blocks（堆块）
– —>: a start-pointer （头指针）
– -?->: an interior-pointer （内部指针）

Leak Case legend:
– DR: Directly reachable （直接可达）
– IR: Indirectly reachable （不直接可达）
– DL: Directly lost （直接丢失）
– IL: Indirectly lost （不直接丢失）
– (y)XY: it’s XY if the interior-pointer is a real pointer （内部指针是一个真实的指针）
– (n)XY: it’s XY if the interior-pointer is not a real pointer （内部指针不是一个真实的指针）
– (_)XY: it’s XY in either case （任意一个情况）

任意一种情况都可以被归为上述9种情况之一，Valgrind合并其中一些情况，得出4种可能

• “Still reachable（依然可达）”。 这包含情况 1 和 2 (for the BBB blocks) 。 一个内存块的头指针的或者头指针的链被发现，程序员至少在原理上释放了这块内存在程序退出之前。这是一个非常普遍并且不算是一个问题，Valgrind默认不报告这个问题。

• “Definitely lost（绝对丢失）”。 这包含情况3 (for the BBB blocks) 。这意味着这个数据块没有指针可达。数据块被归为丢失，因为程序员在程序结束时不能主动释放它，原因是没有指针指向这块内存。 这可能是在较早之前丢失了指向内存区域的指针。

• “Indirectly lost（非直接丢失）”。这包含情况4和9 (for the BBB blocks)。这意味着数据块丢失不是因为没有指针指向它，而是因为所有的指向数据块的指针自己丢失了。 举例来说，如果你有一个二叉树，根节点丢失，所有的他的子节点都变成非直接丢失。因为根节点的直接丢失问题被解决，子节点的非直接丢失问就会消失。Valgrind默认不报告这个问题。

• “Possibly lost（可能丢失）”。 这包含情况5、6、7、8 (for the BBB blocks) 。 这意味着一个或多个数据块指针被发现，但是至少一个指针是内部指针。这可能只是一个内存中的随机值，刚好指向一个数据块，所以你不需要考虑这个情况除非你知道你的代码中出现了内部指针。

下面是一个内存泄漏的总结的例子

LEAK SUMMARY:
definitely lost: 48 bytes in 3 blocks.
indirectly lost: 32 bytes in 2 blocks.
possibly lost: 96 bytes in 6 blocks.
still reachable: 64 bytes in 4 blocks.
suppressed: 0 bytes in 0 blocks.

如果开启的启发式的选项，类似于以下输出

LEAK SUMMARY:
definitely lost: 4 bytes in 1 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 95 bytes in 6 blocks
of which reachable via heuristic:
stdstring : 56 bytes in 2 blocks
length64 : 16 bytes in 1 blocks
newarray : 7 bytes in 1 blocks
multipleinheritance: 8 bytes in 1 blocks
suppressed: 0 bytes in 0 blocks

如果 –leak-check=full 被指定, Memcheck 会给出每一个绝对丢失或可能丢失块的详细情况，包括他们在哪里被分配。它不能告诉你何时、如何、为何指向一个泄露内存块的指针丢失了;这个需要自己解决。通常，你需要保证在程序退出时，你的程序没有任何的绝对丢失或者可能丢失的内存块。

例如

8 bytes in 1 blocks are definitely lost in loss record 1 of 14
at 0x……..: malloc (vg_replace_malloc.c:…)
by 0x……..: mk (leak-tree.c:11)
by 0x……..: main (leak-tree.c:39)

88 (8 direct, 80 indirect) bytes in 1 blocks are definitely lost in loss record 13 of 14
at 0x……..: malloc (vg_replace_malloc.c:…)
by 0x……..: mk (leak-tree.c:11)
by 0x……..: main (leak-tree.c:25)

第一条信息描述了一种简单的情况，一个8byte的内存块绝对丢失了。第二种情况描述了另外一个8byte内存块绝对丢失;不同在于第二种情况会引起在另外内存块中的更多的80bytes内存非直接丢失了。loss number没有任何特殊的含义。这个loss number可以在Valgrind gdbserver中用来列出泄漏内存块的地址，或者给出更多的信息关于为何一个内存块仍然可达。

当 –leak-check=full 被指定时，选项–show-leak-kinds= 控制显示的泄漏类型。

有下面几种类型：

• 单独指定一或多个： definite indirect possible reachable。
• all代表所有。
• none 代表空集合。

例如使用 –show-leak-kinds=definite,possible 来只显示绝对或者可能的内存丢失。

注意事项

在调试php时,因为php自己实现了内存管理机制,所有使用valgrind时,会检测出很多php上的内存泄露,我们可以通过export USE_ZEND_ALLOC=0来让php直接向内存申请内存,这样有助于发现问题