Valgrind工具集，提供了一堆调试及性能统计工具，可用于帮助将妳的程序变得更快及更正确。这些工具中，最受欢迎的是Memcheck。它可以探测到狠多在C 和C++程序中常见的内存相关的错误，那些错误可能引起崩溃及不可预知的行为。

本指南文档中接下来的部分，就会向妳说明，如何使用Memcheck 来探测程序中的内存相关错误。对于Memcheck 和其它工具的完整文档，请阅读用户手册。

以 -g 选项来编译妳的程序，以在程序中包含调试信息，这样，Memcheck 的错误消息中就能够包含具体的代码行号。 加上 -O0 也会带来一些好处，就是程序会变得狠慢。 使用 -O1 选项的话，错误消息中的代码行号可能变得不准确， 当然，一般来说，Memcheck 对于以 -O1 选项编译的代码工作得相当好，而相对于以 -O0 选项编译的程序来说，运行速度提升相当明显。不使用使用 -O2 及更高级别的优化选项，因为，在那种情况下，偶尔会报告一些“未初始化的值”（uninitialised-value）错误，而实际上并不是真正有错误。

如果妳的程序的正常执行方式是这样的：

  myprog arg1 arg2

那么，妳现在应当这样来执行它了：

  valgrind --leak-check=yes myprog arg1 arg2

Memcheck就是默认被运行的工具。 --leak-check选项用于开启详细内存泄露探测器。

妳的程序会比一般情况下运行得慢(例如，慢上20到30倍)，并且会使用多得多的内存。Memcheck会在探测到内存错误和泄露时输出对应的消息。

以下是一个示例的C 语言程序，源代码文件名为a.c，其中包含着一个内存错误和一处内存泄露。

  #include <stdlib.h>

  void f(void)

  {

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

     x[10] = 0;        // 问题1：堆内存块访问地址超出范围

  }                    // 问题2：内存泄露 -- x并未被释放

  int main(void)

  {

     f();

     return 0;

  }

大部分错误消息都是下面这样的，这个示例说明的是上面的问题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是进程编号；这通常不重要。

• •.第一行("Invalid write...")说明的是错误的类型。此处，程序向一个不应该写入的内存位置写入了内容，因为它的写入位置超出了堆内存块的地址范围。

• •.第一行下面，是一个栈跟踪，告诉妳发生问题的具体位置。栈跟踪可能会变得非常巨大，非常费解，尤其是当妳使用C++ STL 时更是如此。从下向上阅读，通常会比较容易理解。如果栈跟踪还不够大，那么，使用 --num-callers 选项来将它设置得更大。

• •.代码地址(例如0x804838F)通常不重要，但是，有些时候需要用这些信息来跟踪特别奇特的问题。

• •.有些错误消息中会包含第二砣内容，指明与之相关的内存地址。在本示例中，这条错误消息，说明了，当前所写入的内存位置超过了example.c 中第5 行利用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 运行得更慢，但是，通过这个选项获得的额外信息通常能够帮助妳节省大量的时间来找出未初始化的值的最初位置。