Valgrind Memcheck 内存检查

本文主要是介绍Valgrind Memcheck 内存检查，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

原文

Valgrind Memcheck是一种检测内存泄漏和内存错误的工具。一些最困难的C错误来自内存管理不当：分配错误的大小、使用未初始化的指针、释放内存后访问内存、缓冲区溢出等等。这些类型的错误很棘手，因为它们提供的调试信息很少，将观察到的问题追溯到潜在的根本原因可能是一项挑战。Valgrind是来帮忙的！

内存错误与内存泄漏

Valgrind报告两种类型的问题：内存错误和内存泄漏。当一个程序动态分配内存并忘记以后释放内存时，它就会产生泄漏。内存泄漏通常不会导致程序行为异常、崩溃或给出错误答案，并且不是紧急情况。另一方面，内存错误是红色警报。读取未初始化的内存、写过一段内存的末尾、访问已释放的内存以及其他内存错误可能会产生严重的后果。内存错误决不能随意处理或忽略。尽管本指南介绍了如何使用Valgrind查找这两个文件，但请记住，到目前为止，错误是主要问题，内存泄漏通常可以在以后解决。

在Valgrind下运行程序

与调试器一样，Valgrind在可执行文件上运行，因此请确保编译了程序的最新副本。例如，如果你的程序名为memoryLeak，请按如下方式运行：

$ valgrind ./memoryLeak

Valgrind随后将启动并在其内部运行指定程序以检查它。如果需要传递命令行参数，也可以这样做：

$ valgrind ./memoryLeak red blue

完成后，Valgrind将打印其内存使用情况的摘要。如果一切顺利，它将看起来像这样：

==4649== ERROR SUMMARY: 0 errors from 0 contexts
==4649== malloc/free: in use at exit: 0 bytes in 0 blocks.
==4649== malloc/free: 10 allocs, 10 frees, 2640 bytes allocated.
==4649== For counts of detected errors, rerun with: -v
==4649== All heap blocks were freed -- no leaks are possible.

这就是你追求的目的：没有错误和泄漏。另一个有用的指标是分配的数量和分配的总字节数。如果这些数字与我们的示例大致相同（你可以在valgrind下运行解决方案以获得基线），你就会知道内存效率达到了目标。

查找内存错误

内存错误确实是邪恶的。更明显的原因会导致惊人的崩溃，但即使如此，也很难确定崩溃是如何发生的以及为什么发生的。更隐晦的是，一个有内存错误的程序似乎仍然可以正常工作，因为你在很多时候都能做到“幸运”。在几次“成功”的结果之后，你可能会一厢情愿地将看似虚假的灾难性结果视为你想象的虚构，但依靠运气得到正确答案并不是一个好策略。在valgrind下运行可以帮助你追踪可见内存错误的原因，并找到你甚至还不知道的潜在错误。
每次valgrind检测到错误时，它都会打印有关其观察到的内容的信息。每一项都相当简洁——错误的种类、违规指令的源代码行，以及有关所涉及内存的一些信息，但通常这些信息足以将你的注意力引导到正确的位置。下面是valgrind在有问题的程序上运行的一个示例：

==4651== Invalid write of size 1
==4651==    at 0x80486A4: main (myprogram.c:58)
==4651==  Address 0x4449054 is not stack'd, malloc'd or (recently) free'd
==4651==
==4651== ERROR SUMMARY: 1 errors from 1 contexts
==4651== malloc/free: in use at exit: 0 bytes in 0 blocks.
==4651== malloc/free: 1 allocs, 1 frees, 10 bytes allocated.
==4651== For counts of detected errors, rerun with: -v
==4651== All heap blocks were freed -- no leaks are possible.

错误摘要显示有一个错误，大小为1（即字节）的无效写入。在myprogram.c的第58行观察到错误的写入操作。让我们看看代码：

56     ...
57     char *copy = malloc(strlen(buffer));
58     strcpy(copy, buffer);
59     ...

看起来像是经典strlen+1 bug的一个实例。代码没有为“\0”字符分配足够的空间，因此当strcpy在frag[strlen(buffer)]中写入它时，它访问了malloc段末尾以外的内存。尽管代码显然是错误的，但它通常看起来“有效”，因为malloc通常将请求的大小取整为4或8的最接近倍数，并且额外的空间可以弥补不足。“侥幸逃脱”会让你对代码的正确性产生错误的安全感。下一次运行可能会发生奇怪的崩溃，你可能会将其视为侥幸。但是警惕地使用valgrind可以提示错误，以便你能够找到并修复它，而不是等待观察到的可能难以重现的症状。
你可能会在valgrind报告中看到不同类型的内存错误。最常见的是：

• Invalid read/write of size X。观察到程序读/写X字节的内存无效。常见的原因包括访问堆块末尾以外的区域、访问已释放的内存或访问未分配的区域，如使用未初始化的指针。
• Use of uninitialised value 或 Conditional jump or move depends on uninitialised value(s)。程序读取以前未写入的内存位置的值，即使用随机垃圾。第二个更具体地指示在if/for/while中的测试表达式中发生的读取。确保初始化所有变量！请记住，仅仅声明变量并不会在其内容中放入任何内容——如果希望int为0或指针为NULL，则必须显式声明。请注意，Valgrind将静默地允许程序将未初始化的值从一个变量传播到另一个变量；只有在最终使用可能远离错误根源的值时，投诉才会出现。跟踪未初始化的值时，使用附加标志--track-origins=yes运行Valgrind，它会将该值的整个历史记录报告回原点，这可能非常有用。
• Source and destination overlap in memcpy() 。程序试图将数据从一个位置复制到另一个位置，要读取的范围与要写入的范围相交。使用memcpy在重叠区域之间传输数据可能会破坏结果；memmove是在这种情况下的正确函数。
• Invalid free()。程序多次尝试释放非堆地址或释放同一块内存。

你的任务中的内存错误可能会导致各种各样的问题（输出错误、崩溃、挂起），并将受到显著的评分扣减。确保尽早并经常运行Valgrind，快速解决任何内存错误！

查找内存泄漏

你可以要求Valgrind报告内存泄漏。当你分配堆内存但不释放它时，这称为泄漏。对于运行并立即退出的小型短生命周期的程序，泄漏是无害的，但对于规模更大和/或寿命更长的项目，重复的小型泄漏最终可能累积起来。对于CS107课程，我们希望你在程序执行结束时释放所有内存。
例如，让我们以memoryLeak.c程序为例：

#include<stdlib.h>
#include<stdio.h>
#include<time.h>const int ARR_SIZE = 1000;int main() {// create an array of ARR_SIZE intsint *intArray = malloc(sizeof(int) * ARR_SIZE);// populate themfor (int i=0; i < ARR_SIZE; i++) {intArray[i] = i;}// print one out// first, seed the random number generatorsrand(time(NULL));int randNum = rand() % ARR_SIZE;printf("intArray[%d]: %d\n", randNum, intArray[randNum]);// end without freeing!return 0;
}

如果我们编译并运行它，下面是我们得到的输出：

$ gcc -g -Og -std=gnu99 memoryLeak.c -o memoryLeak
$ ./memoryLeak
intArray[645]: 645

这似乎没问题，但让我们在Valgrind下运行它：

$ valgrind ./memoryLeak
==32251== Memcheck, a memory error detector
==32251== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==32251== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==32251== Command: ./memoryLeak
==32251== 
intArray[782]: 782
==32251== 
==32251== HEAP SUMMARY:
==32251==     in use at exit: 4,000 bytes in 1 blocks
==32251==   total heap usage: 2 allocs, 1 frees, 5,024 bytes allocated
==32251== 
==32251== LEAK SUMMARY:
==32251==    definitely lost: 4,000 bytes in 1 blocks
==32251==    indirectly lost: 0 bytes in 0 blocks
==32251==      possibly lost: 0 bytes in 0 blocks
==32251==    still reachable: 0 bytes in 0 blocks
==32251==         suppressed: 0 bytes in 0 blocks
==32251== Rerun with --leak-check=full to see details of leaked memory
==32251== 
==32251== For counts of detected and suppressed errors, rerun with: -v
==32251== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
$

当泄漏发生时，很容易判断：alloc/free计数不匹配，最后会出现泄漏摘要部分。（请注意，虽然我们只调用malloc一次，但它显示了2个alloc。为什么？因为srand/time在它们的实现中分配内存，但它们也释放了内存！）。Valgrind还提供了关于每个泄漏的一些数据——有多少字节，发生了多少次，以及原始分配在代码中的什么位置。由同一原因导致的多个泄漏合并为一个条目，该条目汇总了多个块中的字节总数。在这里，程序memoryLeak.c从堆中请求内存，然后在不释放内存的情况下结束。这是内存泄漏，valgrind正确地找到了泄漏：“绝对丢失：1个块中有4000字节”
Valgrind使用以下术语对泄漏进行分类：

• 绝对丢失(definitely lost)：从未释放的堆分配内存，程序不再有指向该内存的指针。Valgrind知道你曾经有过指针，但后来就失去了它的踪迹。这段记忆绝对是孤儿。
• 间接丢失(indirectly lost)：从未释放的堆分配内存，指向它的唯一指针也将丢失。例如，如果孤立一个链表，第一个节点肯定会丢失，随后的节点将间接丢失。
• 可能丢失(possibly lost)：从未释放的堆分配内存，valgrind无法确定是否有指针。
• 仍然可访问(still reachable)：从未释放的堆分配内存，程序在其出口处仍然有一个指针。

这些分类指示该程序是否在退出时保留了指向内存的指针。如果指针可用，则添加必要的空闲调用会更容易一些，但这并不会改变所有内存都是泄漏的事实——也就是说，内存是堆分配的，从未释放过。
考虑到泄漏通常不会导致错误，错误的释放也会导致错误，我们建议你在程序完成之前不要担心释放内存。然后，你可以返回并根据需要释放内存，确保每个步骤的正确性。
如果需要更多信息，需要包括选项--leak-check=full和--show-leak-kinds=all

$ valgrind --leak-check=full --show-leak-kinds=all ./memoryLeak
==4599== Memcheck, a memory error detector
==4599== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==4599== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==4599== Command: ./memoryLeak
==4599== 
intArray[2]: 2
==4599== 
==4599== HEAP SUMMARY:
==4599==     in use at exit: 4,000 bytes in 1 blocks
==4599==   total heap usage: 2 allocs, 1 frees, 5,024 bytes allocated
==4599== 
==4599== 4,000 bytes in 1 blocks are definitely lost in loss record 1 of 1
==4599==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4599==    by 0x4005A3: main (memoryLeak.c:9)
==4599== 
==4599== LEAK SUMMARY:
==4599==    definitely lost: 4,000 bytes in 1 blocks
==4599==    indirectly lost: 0 bytes in 0 blocks
==4599==      possibly lost: 0 bytes in 0 blocks
==4599==    still reachable: 0 bytes in 0 blocks
==4599==         suppressed: 0 bytes in 0 blocks
==4599== 
==4599== For counts of detected and suppressed errors, rerun with: -v
==4599== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

由于我们使用-g标志进行编译，valgrind能够准确地告诉我们程序中泄漏是在哪里产生的：

==4599==    by 0x4005A3: main (memoryLeak.c:9)

换句话说，在memoryLeak.c的第9行，我们分配了内存，但它从未被释放。这在调试程序时非常有用！
有关Valgrind的更多信息，请参阅完整的Valgrind手册。

常见问题

我的程序在Valgrind下运行得很慢。我应该担心吗？
否。Valgrind正在模拟上下文中运行你的程序，并监视运行时活动。根据程序的内存密集程度，此额外检查会使程序速度降低2-5倍。这完全是意料之中的。

Valgrind说我泄漏内存是因为在main()中调用了malloc()，但我没有在main()中调用malloc()！发生什么事？
此报告也可能是在main()中调用库函数的结果，该函数本身在内部调用malloc()。常见的示例包括fopen()和strdup()。确保关闭所有fopen打开的 FILE*，并释放所有strdup返回的 char*。

我的程序运行良好并产生正确的输出，但Valgrind报告显示内存错误。我可以忽略这些吗？
不。在某些情况下，错误可能没有可观察的运行时结果，但这并不意味着它不存在。这个错误就像一颗滴答作响的定时炸弹，随时可能爆炸。忽略它并指望代码继续“走运”是一种危险的做法。确保你的代码始终运行稳定！

我的valgrind报告包含一个看起来不祥的条目，类似这样：“Warning: set address range perms: large range”。这是什么？我需要担心吗？
Valgrind在分配异常大的内存区域时打印此警告，怀疑该区域可能由于错误而过大。如果代码的目的是分配一个大的块，那么一切都很好。

我的valgrind报告建议为“counts of suppressed errors”使用-v重新运行。这些是什么？我应该担心他们吗？
别在意。有些库代码做了一些不寻常的事情，即使操作正确，也会触发Valgrind的报告。这些错误/泄漏被抑制，因为它们被认为是虚假的。v标志导致valgrind提供有关其内部处理这些事件的详细注释。你可以安全地忽略所有被抑制的事件；你没必要听它唠叨个没完。

当我在没有额外参数的情况下运行valgrind时，ERROR SUMMARY 显示0个错误，但添加--leak-check选项的相同运行会报告N个上下文中的N个错误。我是否有错误？
启用泄漏检查后，valgrind发现的每个不同泄漏都包括在错误计数中。如果未启用泄漏检查（默认设置），它不会枚举/计数泄漏，因此在摘要计数中只报告实际内存错误。

当我尝试在valgrind下运行特定的可执行文件时，即使我可以正常运行该程序，也会收到一条“Permission denied”消息。我怎么修复？
根据可执行文件的文件模式，如果你没有执行权限，Valgrind将拒绝。在我们的Myth系统中，文件模式基本上是不相关的（基于目录的AFS权限优先），但是Valgrind仍然在关注。命令ls -l executable_file显示文件模式位，x表示所有者/组/其他的执行权限。使用命令chmod a+x executable_file为所有用户启用执行权限。

这篇关于Valgrind Memcheck 内存检查的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---