linux实用技巧：检测内存泄漏工具Valgrind
- - CSDN博客系统运维推荐文章1.Valgrind简介. 1.在我们编写C/C++的时候，最常见的错误之一就是内存泄露，这样的问题其实跟程序员的编程习惯密不可分. 如果你在申请内存空间之后能够马上在合适的位置释放内存. 会极大程度的避免内存泄漏的情况. 有时候我们确实忘记释放内存而导致了比较严重的错误，所以这个时候我们需要借助valgrind这个工具来判断内存泄漏.
C/C++的内存泄漏检测工具Valgrind memcheck的使用经历（求大神解答疑惑，找出内存泄露真凶）
标签：
内存泄漏
工具
valgrind
| 发表时间：2014-03-19 05:46 | 作者：lanxuezaipiao
出处：http://blog.csdn.net
Linux下的Valgrind真是利器啊（不知道Valgrind的请自觉查看参考文献（1）（2）），帮我找出了不少C++中的内存管理错误，前一阵子还在纠结为什么VS 2013下运行良好的程序到了Linux下用g++编译运行却崩溃了，给出一堆汇编代码也看不懂。久久不得解过后，想想肯定是内存方面的错误，VS在这方面一般都不检查的，就算你的程序千疮百孔，各种内存泄露、内存管理错误，只要不影响运行，没有读到不该读的东西VS就不会告诉你（应该是VS内部没实现这个内存检测功能），因此用VS写出的程序可能不是完美或健壮的。
下面是我通过 Valgrind第一次检测得到的结果和一点点修改后得到的结果（还没改完，所以还有不少内存泄露问题……）：
第一次检测结果：惨不忍睹，因为程序规模有些大。
根据提示一点点修改过后，虽然还有个别错误和内存泄露问题，但还在修改中，至少已经能成功运行了……
真感谢Valgrind帮我成功找出了一堆内存问题，查找过程中也为自己犯的低级错误而感到羞愧，所以记录下来以便谨记。
1. 最多最低级的错误：不匹配地使用malloc/new/new[] 和 free/delete/delete[]
这样的错误主要源于我对C++的new/new[]、delete/delete[]机制不熟悉，凡是new/new[]分配内存的类型变量我一概用delete进行释放，或者有的变量用malloc进行分配，结果释放的时候却用delete，导致申请、释放很多地方不匹配，很多内存空间没能释放掉。为了维护方便，我后来一律使用new/new[]和delete/delete[]，抛弃C中的malloc和free。
如果将用户new的类型分为基本数据类型和自定义数据类型两种，那么对于下面的操作相信大家都很熟悉，也没有任何问题。
（1）基本数据类型
一维指针：
// 申请空间 int *d = new int[5]; // 释放空间 delete[] d;
二维指针：
// 申请空间
int **d = new int*[5];
for (int i = 0; i < 5; i++)
d[i] = new int[10];
// 释放空间
for (int i = 0; i < 5; i++)
delete[] d[i];
delete[] d; （2）自定义数据类型
比如下面这样一个类型：
class DFA {
bool is_mark;
char *s;
public:
~DFA() { printf("delete it.\n"); }
};
一维指针：
DFA *d = new DFA(); delete d;
二维指针：
// 申请空间
DFA **d = new DFA*[5];
for (int i = 0; i < 5; i++)
d[i] = new DFA();
// 释放空间
for (int i = 0; i < 5; i++)
delete d[i];
delete[]d;
这没有任何问题，因为我们都是配套使用new/delete和new[]/delete[]的。这在Valgrind下检测也是完美通过的，但为什么要这配套使用呢？原理是什么？
虽然深究这些东西好像没什么实际意义，但对于想深入了解C++内部机制或像我一样老是释放出错导致大量内存泄露的小白程序员还是值得研究的，至少知道了为什么，以后就不会犯现在的低级错误。
参考文献（3）是这样描述的：
通常状况下，编译器在new的时候会返回用户申请的内存空间大小，但是实际上，编译器会分配更大的空间，目的就是在delete的时候能够准确的释放这段空间 这段空间在用户取得的指针之前以及用户空间末尾之后存放。 实际上：blockSize = sizeof(_CrtMemBlockHeader) + nSize + nNoMansLandSize; 其中，blockSize 是系统所分配的实际空间大小， _CrtMemBlockHeader是new的头部信息，其中包含用户申请的空间大小等其他一些信息。 nNoMansLandSize是尾部的越界校验大小， 一般是4个字节“FEFEFEFE”，如果用户越界写入这段空间，则校验的时候会assert。nSize才是为我们分配的真正可用的内存空间。 用户new的时候分为两种情况 A. new的是基础数据类型或者是没有自定义析构函数的结构 B. new的是有自定义析构函数的结构体或类 这两者的区别是如果有用户自定义的析构函数，则delete的时候必须要调用析构函数，那么编译器delete时如何知道要调用多少个对象的析构函数呢， 答案就是new的时候，如果是情况B，则编译器会在new头部之后，用户获得的指针之前多分配4个字节的空间用来记录new的时候的数组大小， 这样delete的时候就可以取到个数并正确的调用。
这段描述可能有些晦涩难懂，参考文献（4）给了更加详细的解释，一点即通。这样的解释其实也隐含着一个推论：如果new的是基本数据类型或者是没有自定义析构函数的结构，那么这种情况下编译器不会在用户获得的指针之前多分配4个字节，因为这时候delete时不用调用析构函数，也就是不用知道数组个数的大小（因为只有调用析构函数时才需要知道要调用多少个析构函数，也就是数组的大小），而是直接传入数组的起始地址从而释放掉这块内存空间，此时delete与delete[]是等价的。
因此下面的释放操作也是正确的：
// 申请空间 int *d = new int[5]; // 释放空间 delete d;
将其放在Valgrind下进行检测，结果如下：
==2955== Memcheck, a memory error detector ==2955== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==2955== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==2955== Command: ./test_int ==2955== ==2955== Mismatched free() / delete / delete [] ==2955== at 0x402ACFC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==2955== by 0x8048530: main (in /home/hadoop/test/test_int) ==2955== Address 0x434a028 is 0 bytes inside a block of size 20 alloc'd ==2955== at 0x402B774: operator new[](unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==2955== by 0x8048520: main (in /home/hadoop/test/test_int) ==2955== ==2955== ==2955== HEAP SUMMARY: ==2955== in use at exit: 0 bytes in 0 blocks ==2955== total heap usage: 1 allocs, 1 frees, 20 bytes allocated ==2955== ==2955== All heap blocks were freed -- no leaks are possible ==2955== ==2955== For counts of detected and suppressed errors, rerun with: -v ==2955== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
首先从“All heap blocks were freed -- no leaks are possible”可以看出上面的释放操作的确是正确的，而不是有些人认为的delete d;只会释放d[]的第一个元素的空间，后面的都不会得到释放。但是从“Mismatched free() / delete / delete []”知道Valgrind实际上是不允许这样操作的，虽然没有内存泄露问题，但是new[]与delete不匹配，这样的编程风格不经意间就容易犯低级错误，所以Valgrind报错了，但是我想Valgrind内部实现应该不会考虑的这么复杂，它就检查new是否与delete配对，new[]是否与delete[]配对，而不管有时候new[]与delete配对也不会出现问题的。
综上所述，给我的经验就是：在某些情况下，new[]分配的内存用delete不会出错，但是大多情况下会产生严重的内存问题，所以一定要养成将new和delete，new[]和delete[]配套使用的良好编程习惯。
2. 最看不懂的错误：一堆看不懂的Invalid read/write错误
比如下面这样一个程序：
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
struct accept_pair {
bool is_accept_state;
bool is_strict_end;
char app_name[0];
};
int main() {
char *s = "Alexia";
accept_pair *ap = (accept_pair*)malloc(sizeof(accept_pair) + sizeof(s));
strcpy(ap->app_name, s);
printf("app name: %s\n", ap->app_name);
free(ap);
return 0;
}
首先对该程序做个扼要的说明：
这里结构体里定义零长数组的原因在于我的需求：我在其它地方要用到很大的accept_pair数组，其中只有个别accept_pair元素中的app_name是有效的（取决于某些值的判断，如果为true才给app_name赋值，如果为false则app_name无意义，为空），因此若是char app_name[20]，那么大部分accept_pair元素都浪费了这20个字节的空间，所以我在这里先一个字节都不分配，到时谁需要就给谁分配，遵循“按需分配”的古老思想。可能有人会想，用char *app_name也可以啊，同样能实现按需分配，是的，只是多4个字节而已，属于替补方法。
在g++下经过测试，没有什么问题，能够正确运行，但用Valgrind检测时却报出了一些错误，不是内存泄露问题，而是内存读写错误：
==3511== Memcheck, a memory error detector ==3511== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==3511== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==3511== Command: ./zero ==3511== ==3511== Invalid write of size 1 ==3511== at 0x402CD8B: strcpy (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==3511== by 0x80484E3: main (in /home/hadoop/test/zero) ==3511== Address 0x420002e is 0 bytes after a block of size 6 alloc'd ==3511== at 0x402C418: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==3511== by 0x80484C8: main (in /home/hadoop/test/zero) ==3511== ==3511== Invalid write of size 1 ==3511== at 0x402CDA5: strcpy (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==3511== by 0x80484E3: main (in /home/hadoop/test/zero) ==3511== Address 0x4200030 is 2 bytes after a block of size 6 alloc'd ==3511== at 0x402C418: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==3511== by 0x80484C8: main (in /home/hadoop/test/zero) ==3511== ==3511== Invalid read of size 1 ==3511== at 0x40936A5: vfprintf (vfprintf.c:1655) ==3511== by 0x409881E: printf (printf.c:34) ==3511== by 0x4063934: (below main) (libc-start.c:260) ==3511== Address 0x420002e is 0 bytes after a block of size 6 alloc'd ==3511== at 0x402C418: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==3511== by 0x80484C8: main (in /home/hadoop/test/zero) ==3511== ==3511== Invalid read of size 1 ==3511== at 0x40BC3C0: _IO_file_xsputn@@GLIBC_2.1 (fileops.c:1311) ==3511== by 0x4092184: vfprintf (vfprintf.c:1655) ==3511== by 0x409881E: printf (printf.c:34) ==3511== by 0x4063934: (below main) (libc-start.c:260) ==3511== Address 0x420002f is 1 bytes after a block of size 6 alloc'd ==3511== at 0x402C418: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==3511== by 0x80484C8: main (in /home/hadoop/test/zero) ==3511== ==3511== Invalid read of size 1 ==3511== at 0x40BC3D7: _IO_file_xsputn@@GLIBC_2.1 (fileops.c:1311) ==3511== by 0x4092184: vfprintf (vfprintf.c:1655) ==3511== by 0x409881E: printf (printf.c:34) ==3511== by 0x4063934: (below main) (libc-start.c:260) ==3511== Address 0x420002e is 0 bytes after a block of size 6 alloc'd ==3511== at 0x402C418: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==3511== by 0x80484C8: main (in /home/hadoop/test/zero) ==3511== ==3511== Invalid read of size 4 ==3511== at 0x40C999C: __GI_mempcpy (mempcpy.S:59) ==3511== by 0x40BC310: _IO_file_xsputn@@GLIBC_2.1 (fileops.c:1329) ==3511== by 0x4092184: vfprintf (vfprintf.c:1655) ==3511== by 0x409881E: printf (printf.c:34) ==3511== by 0x4063934: (below main) (libc-start.c:260) ==3511== Address 0x420002c is 4 bytes inside a block of size 6 alloc'd ==3511== at 0x402C418: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==3511== by 0x80484C8: main (in /home/hadoop/test/zero) ==3511== app name: Alexia ==3511== ==3511== HEAP SUMMARY: ==3511== in use at exit: 0 bytes in 0 blocks ==3511== total heap usage: 1 allocs, 1 frees, 6 bytes allocated ==3511== ==3511== All heap blocks were freed -- no leaks are possible ==3511== ==3511== For counts of detected and suppressed errors, rerun with: -v ==3511== ERROR SUMMARY: 9 errors from 6 contexts (suppressed: 0 from 0)从检测报告可以看出：
strcpy(ap->app_name, s);这句是内存写错误，printf("app name: %s\n", ap->app_name);这句是内存读错误，两者都说明Valgrind认为ap->app_name所处内存空间是不合法的，可是我明明已经为其分配了内存空间，只是没有注明这段空间就是给它用的，难道结构体中零长数组char app_name[0]是不能写入值的吗？还是我对零长数组的使用有误？至今仍不得解，求大神解答……
3. 最不明所以的内存泄露：definitely lost/indefinitely lost
请看下面这样一个程序：
#include <stdio.h>
#include <string.h>
class accept_pair {
public:
bool is_accept_state;
bool is_strict_end;
char *app_name;
public:
accept_pair(bool is_accept = false, bool is_end = false);
~accept_pair();
};
class DFA {
public:
unsigned int _size;
accept_pair **accept_states;
public:
DFA(int size);
~DFA();
void add_state(int index, char *s);
void add_size(int size);
};
int main() {
char *s = "Alexia";
DFA *dfa = new DFA(3);
dfa->add_state(0, s);
dfa->add_state(1, s);
dfa->add_state(2, s);
dfa->add_size(2);
dfa->add_state(3, s);
dfa->add_state(4, s);
printf("\napp_name: %s\n", dfa->accept_states[4]->app_name);
printf("size: %d\n\n", dfa->_size);
delete dfa;
return 0;
}
accept_pair::accept_pair(bool is_accept, bool is_end) {
is_accept_state = is_accept;
is_strict_end = is_end;
app_name = NULL;
}
accept_pair::~accept_pair() {
if (app_name) {
printf("delete accept_pair.\n");
delete[] app_name;
}
}
DFA::DFA(int size) {
_size = size;
accept_states = new accept_pair*[_size];
for (int s = 0; s < _size; s++) {
accept_states[s] = NULL;
}
}
DFA::~DFA() {
for (int i = 0; i < _size; i++) {
if (accept_states[i]) {
printf("delete dfa.\n");
delete accept_states[i];
accept_states[i] = NULL;
}
}
delete[] accept_states;
}
void DFA::add_state(int index, char *s) {
accept_states[index] = new accept_pair(true, true);
accept_states[index]->app_name = new char[strlen(s) + 1];
memcpy(accept_states[index]->app_name, s, strlen(s) + 1);
}
void DFA::add_size(int size) {
// reallocate memory for accept_states.
accept_pair **tmp_states = new accept_pair*[size + _size];
for (int s = 0; s < size + _size; s++)
tmp_states[s] = new accept_pair(false, false);
for (int s = 0; s < _size; s++) {
tmp_states[s]->is_accept_state = accept_states[s]->is_accept_state;
tmp_states[s]->is_strict_end = accept_states[s]->is_strict_end;
if (accept_states[s]->app_name != NULL) {
tmp_states[s]->app_name = new char[strlen(accept_states[s]->app_name) + 1];
memcpy(tmp_states[s]->app_name, accept_states[s]->app_name, strlen(accept_states[s]->app_name) + 1);
}
}
// free old memory.
for (int s = 0; s < _size; s++) {
if (accept_states[s] != NULL) {
delete accept_states[s];
accept_states[s] = NULL;
}
}
_size += size;
delete []accept_states;
accept_states = tmp_states;
} 虽然有点长，但逻辑很简单，其中add_size()首先分配一个更大的accept_pair数组，将已有的数据全部拷贝进去，然后释放掉原来的accept_pair数组所占空间，最后将旧的数组指针指向新分配的内存空间。这是个demo程序，在我看来这段程序是没有任何内存泄露问题的，因为申请的所有内存空间最后都会在DFA析构函数中得到释放。但是Valgrind的检测报告却报出了1个内存泄露问题（红色的是程序输出）：
==3093== Memcheck, a memory error detector ==3093== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==3093== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==3093== Command: ./test ==3093== delete accept_pair. delete accept_pair. delete accept_pair. app_name: Alexia size: 5 delete dfa. delete accept_pair. delete dfa. delete accept_pair. delete dfa. delete accept_pair. delete dfa. delete accept_pair. delete dfa. delete accept_pair. ==3093== ==3093== HEAP SUMMARY: ==3093== in use at exit: 16 bytes in 2 blocks ==3093== total heap usage: 21 allocs, 19 frees, 176 bytes allocated ==3093== ==3093== 16 bytes in 2 blocks are definitely lost in loss record 1 of 1 ==3093== at 0x402BE94: operator new(unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==3093== by 0x8048A71: DFA::add_size(int) (in /home/hadoop/test/test) ==3093== by 0x8048798: main (in /home/hadoop/test/test) ==3093== ==3093== LEAK SUMMARY: ==3093== definitely lost: 16 bytes in 2 blocks ==3093== indirectly lost: 0 bytes in 0 blocks ==3093== possibly lost: 0 bytes in 0 blocks ==3093== still reachable: 0 bytes in 0 blocks ==3093== suppressed: 0 bytes in 0 blocks ==3093== ==3093== For counts of detected and suppressed errors, rerun with: -v ==3093== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
说明add_size()这个函数里存在用new申请的内存空间没有得到释放，这一点感觉很费解，开始以为tmp_states指针所指向的数据赋给accept_states后没有及时释放导致的，于是我最后加了句delete tmp_states;结果招致更多的错误。相信不是Valgrind误报，说明我对C++的new和delete机制还是不明不白，一些于我而言不明所以的内存泄露问题真心不得解，希望有人能够告诉我是哪里的问题？
4. 参考文献
（1）
如何使用Valgrind memcheck工具进行C/C++的内存泄漏检测 如何使用Valgrind memcheck工具进行C/C++的内存泄漏检测
（2） valgrind
详细说明
（3） 关于new和delete，new[] 和delete[]
（4） 浅谈 C++ 中的 new/delete 和 new[]/delete[]
作者：lanxuezaipiao 发表于2014-3-18 21:46:04 原文链接
阅读：89 评论：0 查看评论
相关 [内存泄漏 工具 valgrind] 推荐：
内存泄漏检查工具valgrind的安装与使用
- - CSDN博客推荐文章Valgrind是一款用于内存调试、内存泄漏检测以及性能分析的软件工具套装. 它最流行的工具是Memcheck, 它能检测C/C++中大部分的内存相关的错误. 程序编译时使用 “-g”参数，以添加调试信息，这样Memcheck的错误消息可以精确到行；. 编译时使用“-O0”也有必要，只是速度会很慢，“-O1”可能会导致Memecheck的错误消息不正确；.
C/C++的内存泄漏检测工具Valgrind memcheck的使用经历（求大神解答疑惑，找出内存泄露真凶）
- - CSDN博客综合推荐文章Linux下的Valgrind真是利器啊（不知道Valgrind的请自觉查看参考文献（1）（2）），帮我找出了不少C++中的内存管理错误，前一阵子还在纠结为什么VS 2013下运行良好的程序到了Linux下用g++编译运行却崩溃了，给出一堆汇编代码也看不懂. 久久不得解过后，想想肯定是内存方面的错误，VS在这方面一般都不检查的，就算你的程序千疮百孔，各种内存泄露、内存管理错误，只要不影响运行，没有读到不该读的东西VS就不会告诉你（应该是VS内部没实现这个内存检测功能），因此用VS写出的程序可能不是完美或健壮的.
iOS内存泄漏自动检测工具PLeakSniffer
- - 移动开发 - ITeye博客新款Objective-C内存泄漏自动检测工具PLeakSniffer， GitHub地址. 前些天读到WeRead团队分享的一款内存泄漏检测工具 MLeaksFinder，恍惚想起早些时候自己也有过编写这样一个小工具的想法，不知道由于什么原因把这事给忘记了. 在仔细读过MLeaksFinder源码，了解实现思路之后，发现和自己最初的想法并不相同，终于在上个周末战胜拖延症将之前的想法付诸于代码，也就诞生了这款功能类似的内存泄漏检测工具PLeakSniffer.
Meta开源JavaScript内存泄漏监测工具MemLab
- - 掘金 前端上周，Facebook母公司Meta 宣布了开源 MemLab，一个基于 Chromium 的浏览器的 JavaScript 应用程序内存泄漏监测工具. 同时，Facebook 技术团队指出：“应用程序的性能和功能正确性问题通常会被用户立即留意到. 然而内存泄漏却不一样，它不容易被立即察觉，但它每次都会吃掉一大块内存，使得整个网络会话的响应变得非常慢.
Google开源Leak Finder——用于检测内存泄漏的JavaScript工具
- - InfoQ cn近日，Google开源了 Leak Finder，这款工具可以查看JavaScript应用的堆，进而发现内存泄漏. 作为一门垃圾收集语言，JavaScript并不会出现常见的内存泄露情况，特别是像C++等语言中所见到的那种. 但如果依旧将内存分配给那些不再使用的对象，那么应用就会出现内存泄漏；如果泄漏情况很严重，那么应用的性能就会受到影响，甚至无法执行.
内存泄漏
- - CSDN博客系统运维推荐文章程序申请了堆空间，但是“忘记”释放，导致该块区域在程序结束前无法被再次使用导致的. 泄漏时间长了，就会导致用户空间内存不足，严重的导致死机. 如果泄漏比较严重，很容易察觉；但是有些泄漏很缓慢，不容易察觉，但是软件会运行很长时间后，会慢慢导致严重问题，而且当发现症状的时候，基本上已经是比较晚的时候了，想要识别泄漏，还是可以实现的，本篇文章来聊聊内存操作的原理.
神器valgrind
- - 斯巴达第二季其实早在2006年我就用过valgrind，但当时valgrind不能观测daemon的内存泄漏问题，所以后来渐渐用得少了. 今天又遇到一个内存泄漏问题，程序颇大，手工调试不太现实了，所以又想到了valgrind，毕竟在这7年间，valgrind又强大了不少. 查了一下，它已经可以检测daemon进程了，方法在 这里 对应的官方文档在 这里 其中"monitor leak_check full reachable any"相当于设置gdb的breakpoint.
java内存泄漏
- - 编程语言 - ITeye博客不论哪种语言的内存分配方式，都需要返回所分配内存的真实地址，也就是返回一个指针到内存块的首地址. Java中对象是采用new或者反射的方法创建的，这些对象的创建都是在堆（Heap）中分配的，所有对象的回收都是由Java虚拟机通过垃圾回收机制完成的. GC为了能够正确释放对象，会监控每个对象的运行状况，对他们的申请、引用、被引用、赋值等状况进行监控，Java会使用有向图的方法进行管理内存，实时监控对象是否可以达到，如果不可到达，则就将其回收，这样也可以消除引用循环的问题.
浅谈Java--内存泄漏
- - ITeye博客 JAVA的垃圾回收机制，让许多程序员觉得内存管理不是很重要，但是内存内存泄露的事情恰恰这样的疏忽而发生，特别是对于Android开发，内存管理更为重要，养成良好的习惯，有利于避免内存的泄漏.. 这里可以把许多对象和引用看成是有向图，顶点可以是对象也可以是引用，引用关系就是有向边.