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."); }};

一维指针：

 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 #include #include 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