Valgrind快速入门指南

介绍

Valgrind工具套件提供了许多调试和分析工具，可帮助您更快更准确地完成程序。这些工具中最受欢迎的名为Memcheck。它可以检测C和C ++程序中常见的许多与内存相关的错误，并可能导致崩溃和不可预测的行为。

本指南的其余部分提供了使用Memcheck开始检测程序中的内存错误所需的最少信息。有关Memcheck和其他工具的完整文档，请阅读用户手册。

准备你的程序

编译您的程序-g以包含调试信息，以便Memcheck的错误消息包含确切的行号。使用-O0也是一个好主意，如果你能忍受减速。随着 -O1错误消息的行号可能不准确，但总体上说，在上编译代码运行MEMCHECK -O1作品还算不错，并且与运行速度的提高-O0是相当显著。-O2不建议使用以上内容，因为Memcheck偶尔会报告不真实存在的未初始化值错误。

3.在Memcheck下运行程序

如果你通常运行这样的程序：

  myprog arg1 arg2

使用此命令行：

  valgrind --leak-check = yes myprog arg1 arg2

Memcheck是默认工具。该--leak-check 选项打开详细的内存泄漏检测器。

您的程序运行速度要比正常速度慢（例如20到30次），并且使用更多的内存。Memcheck将发出关于内存错误和它检测到的泄漏的消息。

4.解释Memcheck的输出

这是一个C程序，在一个名为ac的文件中，内存错误和内存泄漏。

  #include <stdlib.h>void f（void）{int * x = malloc（10 * sizeof（int））;x [10] = 0; //问题1：堆块超载} //问题2：内存泄漏 -  x未释放int main（void）{F（）;返回0;}

大多数错误消息如下所示，其中描述了问题1，堆块溢出：

  == 19182 ==无效的写入大小4== 19182 == at 0x804838F：f（example.c：6）== 19182 == by 0x80483AB：main（example.c：11）== 19182 ==地址0x1BA45050是大小为40的块后的0个字节== 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; 通常不重要。
第一行（“无效写入...”）告诉您是什么样的错误。在这里，程序写入一些内存，它不应该由于堆块超载。
第一行下方是堆栈跟踪，告诉您发生问题的位置。堆栈跟踪可能会变得相当大，并且令人困惑，尤其是在使用C ++ STL时。从底部读取它们可以帮助。如果堆栈跟踪不够大，请使用该--num-callers选项使其更大。
代码地址（例如，0x804838F）通常不重要，但是对于跟踪恶意错误，偶尔至关重要。
一些错误消息有一个第二个组件描述所涉及的内存地址。这一个表明，写入的内存刚刚超过了在example.c的第5行分配了malloc（）的块的结尾。

这是按照报告的顺序修复错误，因为以前的错误可能是由早期错误引起的。没有这样做是Memcheck的常见原因。

内存泄漏消息如下所示：

  == 19182 == 1个块中的40个字节绝对丢失在1中的损失记录1中== 19182 == at 0x1B8FF5CD：malloc（vg_replace_malloc.c：130）== 19182 == by 0x8048385：f（ac：5）== 19182 == by 0x80483AB：main（ac：11）

堆栈跟踪告诉您泄漏内存被分配的位置。Memcheck不能告诉你为什么内存泄漏，不幸的是。（忽略“vg_replace_malloc.c”，这是一个实现细节。）

有几种泄漏; 两个最重要的类别是：

“绝对丢失”：你的程序泄漏记忆 - 修复它！
“可能丢失”：你的程序泄漏记忆，除非你用指针来做有趣的事情（比如把它们指向堆块的中间）。

Memcheck还报告未初始化值的使用，最常见的消息是“有条件跳转或移动取决于未初始化的值”。确定这些错误的根本原因可能很困难。尝试使用--track-origins=yes以获取额外的信息。这使Memcheck运行速度更慢，但是您获得的额外信息通常可以节省大量时间来确定未初始化值的来源。

如果你不理解的错误信息，请参阅从MEMCHECK错误消息的说明中Valgrind的用户手册拥有所有错误信息MEMCHECK产生的例子。

注意事项

Memcheck不完美; 它偶尔会产生误报，并且存在抑制这些功能的机制（请参阅禁止Valgrind用户手册中的错误）。但是，99％的时间通常是正确的，所以你应该谨防忽略其错误信息。毕竟，你不会忽略编译器生成的警告信息，对吧？如果Memcheck报告不能更改的库代码中的错误，则抑制机制也很有用。默认抑制集隐藏了很多，但您可能会遇到更多。

Memcheck无法检测您的程序所具有的每个内存错误。例如，它无法检测到静态或堆栈上分配的数组的超范围读取或写入。但它应该会检测到可能会导致程序崩溃的许多错误（例如导致分段错误）。

尝试使您的程序如此干净，Memcheck报告没有错误。一旦你达到这个状态，更容易看出，当程序更改导致Memcheck报告新的错误。Memcheck使用几年的经验表明，可以使甚至巨大的程序运行Memcheck-clean。例如，KDE，OpenOffice.org和Firefox的大部分都是Memcheck-clean，或者非常接近它。