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

  • Invalid read/write of size X。观察到程序读/写X字节的内存无效。常见的原因包括访问堆块末尾以外的区域、访问已释放的内存或访问未分配的区域,如使用未初始化的指针。
  • Use of uninitialised valueConditional jump or move depends on uninitialised value(s)。程序读取以前未写入的内存位置的值,即使用随机垃圾。第二个更具体地指示在if/for/while中的测试表达式中发生的读取。确保初始化所有变量!请记住,仅仅声明变量并不会在其内容中放入任何内容——如果希望int0或指针为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 ints
    int *intArray = malloc(sizeof(int) * ARR_SIZE);

    // populate them
    for (int i=0; i < ARR_SIZE; i++) {
        intArray[i] = i;
    }

    // print one out
    // first, seed the random number generator
    srand(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为所有用户启用执行权限。

  • 3
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值