Valgrind Memcheck 内存检查

2024-02-19 05:48

本文主要是介绍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 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 内存检查的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/723671

相关文章

NameNode内存生产配置

Hadoop2.x 系列,配置 NameNode 内存 NameNode 内存默认 2000m ,如果服务器内存 4G , NameNode 内存可以配置 3g 。在 hadoop-env.sh 文件中配置如下。 HADOOP_NAMENODE_OPTS=-Xmx3072m Hadoop3.x 系列,配置 Nam

JVM内存调优原则及几种JVM内存调优方法

JVM内存调优原则及几种JVM内存调优方法 1、堆大小设置。 2、回收器选择。   1、在对JVM内存调优的时候不能只看操作系统级别Java进程所占用的内存,这个数值不能准确的反应堆内存的真实占用情况,因为GC过后这个值是不会变化的,因此内存调优的时候要更多地使用JDK提供的内存查看工具,比如JConsole和Java VisualVM。   2、对JVM内存的系统级的调优主要的目的是减少

JVM 常见异常及内存诊断

栈内存溢出 栈内存大小设置:-Xss size 默认除了window以外的所有操作系统默认情况大小为 1MB,window 的默认大小依赖于虚拟机内存。 栈帧过多导致栈内存溢出 下述示例代码,由于递归深度没有限制且没有设置出口,每次方法的调用都会产生一个栈帧导致了创建的栈帧过多,而导致内存溢出(StackOverflowError)。 示例代码: 运行结果: 栈帧过大导致栈内存

理解java虚拟机内存收集

学习《深入理解Java虚拟机》时个人的理解笔记 1、为什么要去了解垃圾收集和内存回收技术? 当需要排查各种内存溢出、内存泄漏问题时,当垃圾收集成为系统达到更高并发量的瓶颈时,我们就必须对这些“自动化”的技术实施必要的监控和调节。 2、“哲学三问”内存收集 what?when?how? 那些内存需要回收?什么时候回收?如何回收? 这是一个整体的问题,确定了什么状态的内存可以

husky 工具配置代码检查工作流:提交代码至仓库前做代码检查

提示:这篇博客以我前两篇博客作为先修知识,请大家先去看看我前两篇博客 博客指路:前端 ESlint 代码规范及修复代码规范错误-CSDN博客前端 Vue3 项目开发—— ESLint & prettier 配置代码风格-CSDN博客 husky 工具配置代码检查工作流的作用 在工作中,我们经常需要将写好的代码提交至代码仓库 但是由于程序员疏忽而将不规范的代码提交至仓库,显然是不合理的 所

NGINX轻松管理10万长连接 --- 基于2GB内存的CentOS 6.5 x86-64

转自:http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=190176&id=4234854 一 前言 当管理大量连接时,特别是只有少量活跃连接,NGINX有比较好的CPU和RAM利用率,如今是多终端保持在线的时代,更能让NGINX发挥这个优点。本文做一个简单测试,NGINX在一个普通PC虚拟机上维护100k的HTTP

PHP原理之内存管理中难懂的几个点

PHP的内存管理, 分为俩大部分, 第一部分是PHP自身的内存管理, 这部分主要的内容就是引用计数, 写时复制, 等等面向应用的层面的管理. 而第二部分就是今天我要介绍的, zend_alloc中描写的关于PHP自身的内存管理, 包括它是如何管理可用内存, 如何分配内存等. 另外, 为什么要写这个呢, 因为之前并没有任何资料来介绍PHP内存管理中使用的策略, 数据结构, 或者算法. 而在我们

string字符会调用new分配堆内存吗

gcc的string默认大小是32个字节,字符串小于等于15直接保存在栈上,超过之后才会使用new分配。

PHP内存泄漏问题解析

内存泄漏 内存泄漏指的是在程序运行过程中申请了内存,但是在使用完成后没有及时释放的现象, 对于普通运行时间较短的程序来说可能问题不会那么明显,但是对于长时间运行的程序, 比如Web服务器,后台进程等就比较明显了,随着系统运行占用的内存会持续上升, 可能会因为占用内存过高而崩溃,或被系统杀掉 PHP的内存泄漏 PHP属于高级语言,语言级别并没有内存的概念,在使用过程中完全不需要主动申请或释放内

C++学习笔记----6、内存管理(四)---- 通常的内存陷阱(2)

3、Windows环境下使用Visual C++发现并修复内存渗露         内存渗露很难跟踪是因为你无法很容易地看着内存并且看到什么对象处于使用中,一开始在哪儿分配的内存。然而,是有程序可以为你做到这一点的。内存渗露检测工具有昂贵的专业软件包,也有免费下载的工具。如果你是在Microsoft Visual C++环境下工作,它的排错工具库有内建的对于内存渗露检测的支持。该内存检测默认没有