DEBUG神器valgrind之memcheck报告分析

2024-02-20 14:18

本文主要是介绍DEBUG神器valgrind之memcheck报告分析,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

memcheck怎么运行

valgrind --log-file=valgrind.log --tool=memcheck --leak-check=full --show-reachable=no --workaround-gcc296-bugs=yes ./mcsample arg1 arg2
–log-file 表示输出报告文件,可以是相对路径或完全路径
–tool=memcheck 做内存检测就是memcheck,要知道valgrind是一个工具集
–leak-check=full 完整检测
–show-reachable=no 是否显示reachable详见内存泄露部分,通常是no,也可以改成yes
–workaround-gcc296-bugs=yes 如果你的gcc存在对应的bug,则要设为yes,否则有误报
最后是被检测程序及其参数。

memcheck报告怎么看

先来一段意外的写错

int main(int argc, char *argv[])
{char* bigBuff = (char*)malloc[1024];free(bigBuff);
}
==3498== Invalid free() / delete / delete[] / realloc()
==3498==    at 0x402B06C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==3498==    by 0x8048444: main (main.cpp:19)
==3498==  Address 0x40c0500 is in the Text segment of /lib/i386-linux-gnu/libc-2.15.so

代码错误的将malloc()写成了malloc[],相当于取得了malloc函数指针后面的地址,输出报告告诉我们这个地址位于.text段。

可以看出报告的基本格式是:

{问题描述}   
at {地址、函数名、模块或代码行} 
by {地址、函数名、代码行}
by ...{逐层依次显示调用堆栈}
Address 0x???????? {描述地址的相对关系}

而报告的输出文档整体格式则可以总结为:

1. copyright 版权声明
2. 异常读写报告
2.1 主线程异常读写
2.2 线程A异常读写报告
2.3 线程B异常读写报告
2... 其他线程
3. 堆内存泄露报告
3.1 堆内存使用情况概述(HEAP SUMMARY)
3.2 确信的内存泄露报告(definitely lost)
3.3 可疑内存操作报告 (show-reachable=no关闭)
3.4 泄露情况概述(LEAK SUMMARY)

都有哪些常见异常报告

内存泄漏

int main(int argc, char *argv[])
{char* bigBuff = (char*)malloc(1024);
}
1,024 bytes in 1 blocks are definitely lost in loss record 1 of 1at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)by 0x8048414: main (main.cpp:17)

definitely lost:内存没有被释放,且没有任何指针指向这里。肯定泄漏了。报告给出的堆栈是内存被分配时的调用堆栈,它可以基本明确内存是由什么业务逻辑创建的。
still reachable:是说内存没有被释放,尽管如此仍有指针指向,内存仍在使用中,这可以不算泄露。(程序退出时仍在工作的异步系统调用?)
possibly lost:是说可能有泄漏,一般是有二级指针(指针的指针)等复杂情况不易于追踪时出现。
suppressed:统计了使用valgrind的某些参数取消了特定库的某些错误,会被归结到这里

异常释放

int main(int argc, char *argv[])
{char* bigBuff = (char*)malloc(1024);char* offsetBuff = bigBuff + 888;free(offsetBuff);
}
 Invalid free() / delete / delete[] / realloc()at 0x402B06C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)by 0x8048461: main (main.cpp:24)Address 0x41f23a0 is 888 bytes inside a block of size 1,024 alloc'dat 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)by 0x8048444: main (main.cpp:17)

free() / delete / delete[] / realloc() 四种中的任一种,这里是free的非法释放。在描述地址的相对关系时,使用了一个句子,句子的格式是:Address 0x???????? is {x} bytes {inside/before/after} a block of size {y} {alloc’d/free’d}

它表示了释放的地址与一个y长度块的相对位置关系。如果地址位于块前,则用before,位于块内则用inside,块后则是after。而最后的alloc’d代表这个y长度的块处于有效状态,其分配时的栈如下;而free’d代表y长度块已删除,其删除时的栈如下。

所以上面的报告可以解释为:地址0x41f23a0位于一个长度1024的有效块内+888处,其分配时的调用堆栈如下。

非法读写

int main(int argc, char *argv[])
{char* bigBuff = (char*)malloc(1024);uint64_t* bigNum = (uint64_t*)(bigBuff+1020);*bigNum = 0x12345678AABBCCDD;printf("bigNum is %llu\n",*bigNum);free(bigBuff);
}
Invalid write of size 4at 0x8048490: main (main.cpp:19)
Address 0x41f2428 is 0 bytes after a block of size 1,024 alloc'dat 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)by 0x8048474: main (main.cpp:17)Invalid read of size 4at 0x804849B: main (main.cpp:20)
Address 0x41f2428 is 0 bytes after a block of size 1,024 alloc'dat 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)by 0x8048474: main (main.cpp:17)

对一个内存区的使用超过了分配的大小时,可以触发Invalid write/read,同时被告知长度。
本例中uint64_t8字节长,访问超出了4字节。
如果将bigBuff+1020改成bigBuff-20,那么报告中会准确的告诉你Address xxx is 20 bytes before a block of …

另外一个有趣的现象是,我发现对uint64_t的非法访问会产生24字节长度非法访问的报告,这说明了什么?

不匹配的释放

int main(int argc, char *argv[])
{int unused;char* bigBuff = (char*)malloc(1024);delete[] bigBuff;printf("unused=%d",unused);
}
Mismatched free() / delete / delete []at 0x402A8DC: operator delete[](void*) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)by 0x80484FB: main (main.cpp:19)
Address 0x4323028 is 0 bytes inside a block of size 1,024 alloc'dat 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)by 0x80484E4: main (main.cpp:18)Use of uninitialised value of size 4at 0x416E0DB: _itoa_word (_itoa.c:195)by 0x417221A: vfprintf (vfprintf.c:1629)by 0x4178B2E: printf (printf.c:35)by 0x41454D2: (below main) (libc-start.c:226)

不管malloc分配后用delete还是delete[],又或者是new[]之后粗心用delete释放,都会得到Mismatched free() / delete / delete []报告,且报告主体内容基本一致。

使用未初始的值

上例中int unused并未赋值即被使用,得到了Use of uninitialised value of size 4的报告,这样的问题通常不致命,但是也需要排除。

可以观察到一个有趣情况,堆栈最后一层首次出现了(below main),它表示代码位于main函数以外被执行,也并非来自于线程,我还不能明确解释这种现象,但是我做了下面这个测试:…

静态构造和释放

class GlobalClass
{
public:GlobalClass(){char* buf = (char*)malloc(10);*(int*)(buf+8) = 100;free(buf);}~GlobalClass(){char* buf = (char*)malloc(10);*(int*)(buf+8) = 100;free(buf);}void fake(){}
} g_globalClass;int main(int argc, char *argv[])
{g_globalClass.fake();
}
Invalid write of size 4at 0x804857B: GlobalClass::GlobalClass() (main.cpp:21)by 0x804850F: __static_initialization_and_destruction_0(int, int) (main.cpp:31)by 0x8048551: _GLOBAL__sub_I_g_globalClass (main.cpp:55)by 0x8048631: __libc_csu_init (in /home/jinzeyu/codelocal/build-mcsample-Desktop_Qt_5_3_GCC_32bit-Debug/mcsample)by 0x4060469: (below main) (libc-start.c:185)
Address 0x41f2030 is 8 bytes inside a block of size 10 alloc'dat 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)by 0x8048571: GlobalClass::GlobalClass() (main.cpp:20)by 0x804850F: __static_initialization_and_destruction_0(int, int) (main.cpp:31)by 0x8048551: _GLOBAL__sub_I_g_globalClass (main.cpp:55)by 0x8048631: __libc_csu_init (in /home/jinzeyu/codelocal/build-mcsample-Desktop_Qt_5_3_GCC_32bit-Debug/mcsample)by 0x4060469: (below main) (libc-start.c:185)Invalid write of size 4at 0x80485B9: GlobalClass::~GlobalClass() (main.cpp:27)by 0x4079B80: __run_exit_handlers (exit.c:78)by 0x4079C0C: exit (exit.c:100)by 0x40604DA: (below main) (libc-start.c:258)
Address 0x41f2070 is 8 bytes inside a block of size 10 alloc'dat 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)by 0x80485AF: GlobalClass::~GlobalClass() (main.cpp:26)by 0x4079B80: __run_exit_handlers (exit.c:78)by 0x4079C0C: exit (exit.c:100)by 0x40604DA: (below main) (libc-start.c:258)

静态类的构造和释放都在main之外,所以都出现了(below main)的字样,堆栈的函数名也很好的证实了这两个过程。这里我联想到了另一个问题,就是静态构造的顺序不一定按预期,强烈建议静态对象之间不要有依赖关系。

崩溃

如果在memcheck运行你的程序过程中遇到崩溃,它依然能够提供一些有用的信息

--16198-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--16198-- si_code=1;  Faulting address: 0x74207972;  sp: 0x6564ca5c
valgrind: the 'impossible' happened:Killed by fatal signal
==16198==    at 0x380C0AD4: ??? (in /usr/lib/valgrind/memcheck-x86-linux)
==16198==    by 0x380C12C5: ??? (in /usr/lib/valgrind/memcheck-x86-linux)
==16198==    by 0x38040A63: ??? (in /usr/lib/valgrind/memcheck-x86-linux)
==16198==    by 0x38040B36: ??? (in /usr/lib/valgrind/memcheck-x86-linux)
==16198==    by 0x3803EA4B: ??? (in /usr/lib/valgrind/memcheck-x86-linux)
==16198==    by 0x20202E78: ???sched status:running_tid=3

然后报告中依次罗列崩溃时各线程所处的堆栈和线程的运行状态

Thread 1: status = VgTs_WaitSys
...Thread 2: status = VgTs_WaitSys
...Thread 3: status = VgTs_Runnable
==16198==    at 0x402C9B4: operator new(unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==16198==    by 0x437D7D3: std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16)
==16198==    by 0x437FBB5: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16)
==16198==    by 0x82A76A3: DataChecker::handle_data_check_resp_msg(void*) (data_checker.c:55)
==16198==    by 0x8144411: main_thread(void*) (main_thread.c:198)
==16198==    by 0x82839CF: thread_manager_start_routine(void*) (thread_manager.c:72)
==16198==    by 0x42D3D4B: start_thread (pthread_create.c:308)
==16198==    by 0x450BFDD: clone (clone.S:130)Thread 4: status = VgTs_WaitSys
...

那么,运行中的线程自然是嫌疑最大的,我们可以提取它的堆栈信息做进一步分析。

这篇关于DEBUG神器valgrind之memcheck报告分析的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!


原文地址:
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.chinasem.cn/article/728495

相关文章

MySQL中的LENGTH()函数用法详解与实例分析

《MySQL中的LENGTH()函数用法详解与实例分析》MySQLLENGTH()函数用于计算字符串的字节长度,区别于CHAR_LENGTH()的字符长度,适用于多字节字符集(如UTF-8)的数据验证... 目录1. LENGTH()函数的基本语法2. LENGTH()函数的返回值2.1 示例1:计算字符串

Android kotlin中 Channel 和 Flow 的区别和选择使用场景分析

《Androidkotlin中Channel和Flow的区别和选择使用场景分析》Kotlin协程中,Flow是冷数据流,按需触发,适合响应式数据处理;Channel是热数据流,持续发送,支持... 目录一、基本概念界定FlowChannel二、核心特性对比数据生产触发条件生产与消费的关系背压处理机制生命周期

怎样通过分析GC日志来定位Java进程的内存问题

《怎样通过分析GC日志来定位Java进程的内存问题》:本文主要介绍怎样通过分析GC日志来定位Java进程的内存问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录一、GC 日志基础配置1. 启用详细 GC 日志2. 不同收集器的日志格式二、关键指标与分析维度1.

MySQL中的表连接原理分析

《MySQL中的表连接原理分析》:本文主要介绍MySQL中的表连接原理分析,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录1、背景2、环境3、表连接原理【1】驱动表和被驱动表【2】内连接【3】外连接【4编程】嵌套循环连接【5】join buffer4、总结1、背景

python中Hash使用场景分析

《python中Hash使用场景分析》Python的hash()函数用于获取对象哈希值,常用于字典和集合,不可变类型可哈希,可变类型不可,常见算法包括除法、乘法、平方取中和随机数哈希,各有优缺点,需根... 目录python中的 Hash除法哈希算法乘法哈希算法平方取中法随机数哈希算法小结在Python中,

Java Stream的distinct去重原理分析

《JavaStream的distinct去重原理分析》Javastream中的distinct方法用于去除流中的重复元素,它返回一个包含过滤后唯一元素的新流,该方法会根据元素的hashcode和eq... 目录一、distinct 的基础用法与核心特性二、distinct 的底层实现原理1. 顺序流中的去重

关于MyISAM和InnoDB对比分析

《关于MyISAM和InnoDB对比分析》:本文主要介绍关于MyISAM和InnoDB对比分析,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录开篇:从交通规则看存储引擎选择理解存储引擎的基本概念技术原理对比1. 事务支持:ACID的守护者2. 锁机制:并发控制的艺

MyBatis Plus 中 update_time 字段自动填充失效的原因分析及解决方案(最新整理)

《MyBatisPlus中update_time字段自动填充失效的原因分析及解决方案(最新整理)》在使用MyBatisPlus时,通常我们会在数据库表中设置create_time和update... 目录前言一、问题现象二、原因分析三、总结:常见原因与解决方法对照表四、推荐写法前言在使用 MyBATis

Python主动抛出异常的各种用法和场景分析

《Python主动抛出异常的各种用法和场景分析》在Python中,我们不仅可以捕获和处理异常,还可以主动抛出异常,也就是以类的方式自定义错误的类型和提示信息,这在编程中非常有用,下面我将详细解释主动抛... 目录一、为什么要主动抛出异常?二、基本语法:raise关键字基本示例三、raise的多种用法1. 抛

github打不开的问题分析及解决

《github打不开的问题分析及解决》:本文主要介绍github打不开的问题分析及解决,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录一、找到github.com域名解析的ip地址二、找到github.global.ssl.fastly.net网址解析的ip地址三