C++雾中风景番外篇3:GDB与Valgrind ,调试代码内存的工具

  1. 云栖社区>
  2. 博客列表>
  3. 正文

C++雾中风景番外篇3:GDB与Valgrind ,调试代码内存的工具

happenlee 2018-11-08 19:45:37 浏览1522 评论0

摘要: 写 C++的同学想必有太多和内存打交道的血泪经验了,常常被 C++的内存问题搅的焦头烂额。(写 core 的经验了)有很多同学一见到 core 就两眼一抹黑,不知所措了。笔者 入"坑"C++之后,在调试 C++代码的过程之中,学习了不少调试代码内存的工具。

写 C++的同学想必有太多和内存打交道的血泪经验了,常常被 C++的内存问题搅的焦头烂额。(写 core 的经验了)有很多同学一见到 core 就两眼一抹黑,不知所措了。笔者 入""C++之后,在调试 C++代码的过程之中,学习了不少调试代码内存的工具。希望借这个机会来介绍一下笔者常用的工具,GDB,Valgrind等等,相信大家通过好好运用这些工具,能更好的驯服内存这匹"野马"。

1.利用 GDB 调试 CoreDump

CoreDump时一个二进制的文件,进程发生错误崩溃时,内核会产生一个瞬时的快照,记录该进程的内存、运行堆栈状态等信息保存在core文件之中。做个简单的类比,core 文件相当于飞机运行时的"黑匣子",能够帮助我们更好的调试 C++程序的问题。OK,接下来笔者将介绍一下如果利用GDB 来调试 CoreDump的文件。

  • CoreDump 文件的大小

首先我们先确定一下操作系统是否会产生 CoreDump 文件。通过ulimit -c获取 core 文件的限制大小:
查看 core 文件的大小限制

上面显示笔者电脑的 core 文件的大小是0,我们需要调整一下。通过ulimit调整为无限制。当然这种调整是临时的,reboot 之后就恢复为0了。

ulimit -c ulimited

如果需要永久修改,可以通过/etc/security/limits.conf 来修改 core 文件的大小。

  • CoreDump 文件的生成路径
    默认情况下,core dump生成的文件名为core,而且就在程序当前目录下。通过修改/proc/sys/kernel/core_pattern可以控制core文件保存位置和文件格式。(建议将后缀改为进程号) 笔者这里简单起见,不进行修改了。
  • 编写core 代码,这里笔者利用线程访问了空指针
#include <unistd.h>
#include <thread>

void core() {
    char* ch = nullptr;
    *ch = 'a';
}

int main() {
    auto t1 = std::thread(core);
    sleep(5);
    return 0;
}
  • 编译运行该代码,产生段错误,生成了 core 文件
    图片.png
  • 利用 GDB 调试 core 文件
    调试 core 文件需要利用原生编译出的二进制文件调试。这里有一点需要注意的,如果编译 C++文件之时没有加-g的编译选项,core 文件的调试内容会不够完整。笔者这里建议开启对应的编译选项,这会导致对应的二进制文件变大,编译时间变长。(生产环境可以考虑关闭)使用gdb 二进制文件 core 文件打开 core 文件。

利用 gdb 调试 core 文件

core 文件列出了两个线程的信息。我们需要判断对应的问题代码的定位,接下来我们一起来梳理一下:
info thread查看线程的运行情况,在这里我们就可以判断代码 core 在什么线程之中了,如果还是无法确定,可以通过thread apply all bt列出更加详尽的堆栈信息。

用 info thread 查看线程运行情况
利用 thread apply all bt 显示详尽的堆栈信息
通过上述信息可以确认,thread 1的代码存在问题。我们通过thread 1切换到 thread 1,用bt显示堆栈信息继续追查:
Thread 1的堆栈信息

之后我们来看看令人生疑的栈内容,这里显然栈0是我们怀疑的代码,用frame 1查看。
对应存在『问题』的语句

好了,这里我们找到了引起问题罪魁祸首的代码,访问了空指针。

小结

程序运行的 core 文件是我们调试代码十分重要依据,通过 GDB 可以很好的给出我们修改代码的线索和参考,熟悉掌握GDB 的调试技巧,能够大大解放我们调试问题代码的生产力。

2.利用Valgrind判断内存泄露

亡羊补牢不如未雨绸缪,与其等到出现程序崩溃时使用 GDB 来调试解决,不如事前确认代码之中可能引发的问题。所以笔者接下来要介绍一款来自大不列颠的C++代码分析神器:Valgrind。(Valgrind的作者也通过开发Valgrind获得了第二届Google-O'Reilly开源代码大奖~~~)
Valgrind 十分强大,适用于内存分析,泄漏检测、锁分析,性能评估。笔者也只掌握了一些基本的入门使用。希望这里能够抛砖引玉,更多复杂的用法烦请参考官方文档

Valgrind的安装

Valgrind的安装很简单,笔者的发行版带了对应的 deb 包。通过 apt-get 的包管理工具就可以直接安装了,其他的发行版也可以作为参考。

sudo apt-get install valgrind
Valgrind的使用

与 GDB 类似,Valgrind 同样推荐使用-g作为编译参数。能够更好的对代码进行分析。这里我们依旧使用之前的例子进行测试:

valgrind ./untitiled

下面是 Valgrind 的分析结果:
valgrind 的分析结果

这里有显示Invalid write of size 1,说明这里有一个不合法的写入,并且写入了1个字节的内容。也就是指的是我们之前代码之中写入空指针的行为。

接下来我们要展示 Valgrind更加强大的功能。它展示了程序的内存使用情况,并且给出总结:
valgrind 对内存的分析
这里列出了多种的内存泄露情况:

  • definitely lost: 肯定的内存泄漏,这表示在程序退出时,有内存没有回收,但是也没有指针指向该内存。这种情况最为严重。
  • indirectly lost: 间接的内存泄漏,如类之中定义的指针指向的内存没有回收。这种情况和上述相同。
  • possibly lost: 可能出现内存泄漏。这种情况需要仔细排查,可能代码没有问题,也可能有异常的内存泄露。
  • still reachable: 程序没主动释放内存,在退出时候该内存仍能访问到。这种情况一般问题不大,因为程序退出之后操作系统会回收程序的内存,所以这种情况一般问题不大。

这里没有给出具体泄露的内容,需要加入参数--leak-check=full将完整的结果打印出来,会指出对应的引起内存泄露的具体代码,可以继续深入分析。

代码调优

这里进行代码调优的时,需要利用qcachegrind来进行分析。首先笔者先进行安装:

sudo apt-get install qcachegrind 

之后我们调用Valgrind来生成运行数据:

 valgrind --tool=callgrind -v main(需要分析的程序)

运行之后在目录下生成对应的分析数据,我们用qcachegrind 打开,这里用的代码是笔者之前实现的 SkipList

qcachegrind callgrind.out.29235 

接下来我们来分析对应的结果:
valgrind 的分析结果

上图显示了各个函数的被调用的耗时百分比,我们可以选取对性能感兴趣的函数来进行深入分析。我们下面继续分析其中一个函数被调用和它使用函数的性能情况
insert 的函数被外调用的情况
insert 函数调用函数的情况与耗时分析

所以通过上述数据,我们可以给出性能分析的证据和线索,依据这些信息来更好的优化我们代码的性能。

3.小结

本文介绍了亡羊补牢的工具 GDB,也简介了未雨绸缪的Valgrind 。通过上述工具对C++程序更加深入分析。工欲善其事,必先利其器,希望大家也能好好掌握这些提供生产力的工具,让 C++不再恼人

【云栖快讯】你想见的Java技术专家都在这了,向大佬提问,有问题必答  详情请点击

网友评论

happenlee
文章42篇 | 关注4
关注
兼容Jenkins标准,可提供快速可靠的持续集成与持续交付服务。基于容器技术和阿里云基础服务... 查看详情
Alibaba Cloud Toolkit 面向开发者 IDE 平台,在 IDE (比如 E... 查看详情
一种高性能、高可靠、可平滑扩容的分布式内存数据库服务。 查看详情
为您提供简单高效、处理能力可弹性伸缩的计算服务,帮助您快速构建更稳定、安全的应用,提升运维效... 查看详情
阿里云总监课正式启航

阿里云总监课正式启航