1.得到源代码：http://valgrind.org/->source code 下载最新版的valgrind得到：valgrind-3.2.3.tar.bz2
2.解压安装包：tar -jxvf valgrind-3.2.3
3.解压后生成目录valgrind-3.2.3
4.cd valgrind-3.2.3
5. ./configure
6.make
7.sudo make install
valgrind三大利器：
1.内存错误检测器
2.时间剖析器
3.空间剖析器
3. 在Memcheck下运行程序:
如果你的程序的运行命令如下:
myprog arg1 arg2
则使用如下命令行:
valgrind --leak-check=yes myprog arg1 arg2
Memcheck是valgrind默认的工具，"--leak-check"选项开启了详细内存泄漏检测器；
这时程序会比平时运行得慢很多(如，慢20~30倍)，并且会消耗更多的内存；
程序运行结束后，或你用“CTRL+C”中止程序后，Memcheck将会列出检测到的内存出错和泄漏的信息；
4. Memcheck输出信息示例说明
下面是一个很简单的示例C程序，并带有一个内存错误和一个内存泄漏；
文件名为：a.c
1 #include
2
3 void f(void)
4 {
5 int* x = malloc(10 * sizeof(int));
6 x[10] = 0; // problem 1: heap block overrun
7 } // problem 2: memory leak -- x not freed
8
9 int main(void)
10 {
11 f();
12 return 0;
13 }
Most error messages look like the following, which describes problem 1, the heap block overrun:
错误消息如下，描述了问题1， 内存写越界
==19182== Invalid write of size 4
==19182== at 0x804838F: f (example.c:6)
==19182== by 0x80483AB: main (example.c:11)
==19182== Address 0x1BA45050 is 0 bytes after a block of size 40 alloc’d
==19182== at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130)
==19182== by 0x8048385: f (example.c:5)
==19182== by 0x80483AB: main (example.c:11)
需要注意的信息有：
. 每个错误都会有多行信息说明，需要仔细阅读.
. 19182是进程ID, 通常不重要；
. 第一行("Invalid write..."),说明了是哪种类型的错误；
在这里，是程序写越界了
. 第一行之下的行都是函数调用栈跟踪，说明了问题的发生的地方；
函数调用栈可以很大，如果还使用了C++ STL时，更容易使人混乱；从底向上读有助于理解；
如果函数调用栈不够大，可以使用--num-callers选项来扩大；
. 代码地址(eg. 0x804838F)通常不用关心，有时只是在跟踪怪异的bug时有用；
. 有些错误信息有第二个组成部分，包括内存地址的描述等；
在这个例子中，这部分的信息描述了写内存位于第五行的块分配函数malloc()之后.
按照报告的顺序修正错误很有必要，因为后面的错误可能是前面的错误造成的；
如果不这么做，会导致Memcheck的使用变得很困难；
内存泄漏的信息通常如下：
==19182== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1
==19182== at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130)
==19182== by 0x8048385: f (a.c:5)
==19182== by 0x80483AB: main (a.c:11)
函数调用栈说明了泄漏的内存是在哪分配的；
但是，Memcheck并不能说明为什么内存泄漏的（忽略"vg_replace_malloc.c",它只是一个实现细节）；
有多种类型的内存泄漏，最重要是如下：
. "definitely lost": 你的程序内存泄漏了 -- 需要解决它；
. "probably lost": 你的程序内存泄漏了，可能需要解决；
除非你对指针做了一些特殊的处理(如将其指向堆的中部)
Memcheck同样会报告未初始化值的使用，
对于这种情况，通常的消息是"Conditional jump or move depends on uninitialised value(s)";
追踪这种错误的根源可能很难；
可以尝试使用 “--track-origins=yes”选项来输出额外的信息；
但这会使Memcheck运行得更慢，但有可能追查到未初始化值的根源；
如果你的程序的运行命令如下:
myprog arg1 arg2
则使用如下命令行:
valgrind --leak-check=yes myprog arg1 arg2
Memcheck是valgrind默认的工具，"--leak-check"选项开启了详细内存泄漏检测器；
这时程序会比平时运行得慢很多(如，慢20~30倍)，并且会消耗更多的内存；
程序运行结束后，或你用“CTRL+C”中止程序后，Memcheck将会列出检测到的内存出错和泄漏的信息；
4. Memcheck输出信息示例说明
下面是一个很简单的示例C程序，并带有一个内存错误和一个内存泄漏；
文件名为：a.c
1 #include
2
3 void f(void)
4 {
5 int* x = malloc(10 * sizeof(int));
6 x[10] = 0; // problem 1: heap block overrun
7 } // problem 2: memory leak -- x not freed
8
9 int main(void)
10 {
11 f();
12 return 0;
13 }
Most error messages look like the following, which describes problem 1, the heap block overrun:
错误消息如下，描述了问题1， 内存写越界
==19182== Invalid write of size 4
==19182== at 0x804838F: f (example.c:6)
==19182== by 0x80483AB: main (example.c:11)
==19182== Address 0x1BA45050 is 0 bytes after a block of size 40 alloc’d
==19182== at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130)
==19182== by 0x8048385: f (example.c:5)
==19182== by 0x80483AB: main (example.c:11)
需要注意的信息有：
. 每个错误都会有多行信息说明，需要仔细阅读.
. 19182是进程ID, 通常不重要；
. 第一行("Invalid write..."),说明了是哪种类型的错误；
在这里，是程序写越界了
. 第一行之下的行都是函数调用栈跟踪，说明了问题的发生的地方；
函数调用栈可以很大，如果还使用了C++ STL时，更容易使人混乱；从底向上读有助于理解；
如果函数调用栈不够大，可以使用--num-callers选项来扩大；
. 代码地址(eg. 0x804838F)通常不用关心，有时只是在跟踪怪异的bug时有用；
. 有些错误信息有第二个组成部分，包括内存地址的描述等；
在这个例子中，这部分的信息描述了写内存位于第五行的块分配函数malloc()之后.
按照报告的顺序修正错误很有必要，因为后面的错误可能是前面的错误造成的；
如果不这么做，会导致Memcheck的使用变得很困难；
内存泄漏的信息通常如下：
==19182== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1
==19182== at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130)
==19182== by 0x8048385: f (a.c:5)
==19182== by 0x80483AB: main (a.c:11)
函数调用栈说明了泄漏的内存是在哪分配的；
但是，Memcheck并不能说明为什么内存泄漏的（忽略"vg_replace_malloc.c",它只是一个实现细节）；
有多种类型的内存泄漏，最重要是如下：
. "definitely lost": 你的程序内存泄漏了 -- 需要解决它；
. "probably lost": 你的程序内存泄漏了，可能需要解决；
除非你对指针做了一些特殊的处理(如将其指向堆的中部)
Memcheck同样会报告未初始化值的使用，
对于这种情况，通常的消息是"Conditional jump or move depends on uninitialised value(s)";
追踪这种错误的根源可能很难；
可以尝试使用 “--track-origins=yes”选项来输出额外的信息；
但这会使Memcheck运行得更慢，但有可能追查到未初始化值的根源；