ekylin / 软件技术 / 程序员的福音,C/C++内存泄漏的终极解决方...

分享

   

程序员的福音,C/C++内存泄漏的终极解决方案

2019-09-28  ekylin

用C/C++开发的程序执行效率很高,但却难以驾驭,稍不留神就翻车,每个C/C++程序员都遭受过内存泄漏的困扰。本文提供一种通过wrap malloc查找memory leak的思路,使得你翻车的时候能够自救,而不至于车毁人亡。

程序员的福音,C/C++内存泄漏的终极解决方案

什么是内存泄漏?

动态申请的内存丢失引用,造成没有办法回收它(我知道杠精要说进程退出前系统会统一回收),这便是内存泄漏,内存泄漏对于客户端应用可能不是什么大事,而对于长久运行的服务器程序则是致命的。

Java等编程语言会自动管理内存回收,而C/C++需要显式的释放,有很多手段可以避免内存泄漏,比如RAII,比如智能指针(大多基于引用计数计数),比如内存池。

程序员的福音,C/C++内存泄漏的终极解决方案

理论上,只要我们足够小心,在每次申请的时候,都牢记释放,那这个世界就清净了,但现实往往没有那么美好,比如抛异常了,释放内存的语句执行不到,又或者某菜鸟不小心埋了颗雷,所以,我们必须直面真实的世界,那就是我们会遭遇内存泄漏。

怎么查内存泄漏?

我们可以review代码,但从海量代码里找到隐藏的问题,这如同大海捞针,往往两手空空。

所以,我们需要借助工具,比如valgrind,但这些找内存泄漏的工具,往往对你使用动态内存的方式有某种期待,或者说约束。比如常驻内存的对象会被误报出来,然后真正有用的信息会掩盖在误报的汪洋大海里。很多时候,valgrind碰到现实项目便武功尽废,帮不上什么忙。

所以很多著名的开源项目,为了能用valgrind跑,都费大力气,大幅修改源代码,从而使得项目代码符合valgrind的要求,满足这些要求的项目,用vargrind跑完没有任何报警叫valgrind干净。

既然这些玩意儿都中看不中用,所以,求人不如求己,还得自力更生。

有哪些技术手段?

可以通过operator new/delete,operator new[]/delete[]重载,但这里有很细致的功夫,你需要全面了解,而不是贸然行动,建议看看Effective C++,对operator new系列操作符重载有专门的阐述。

你也可以hook malloc、free等系统调用。

你还可以开启ptmalloc的调试功能,它有时候也能管点用。

什么是动态内存分配器?

动态内存分配器是介于kernel跟应用程序之间的一个函数库,glibc提供的动态内存分配器叫ptmalloc,它也是应用最广泛的动态内存分配器实现。

从kernel角度看,动态内存分配器属于应用程序层;而从应用程序的角度看,动态内存分配器属于系统层。

应用程序可以通过mmap系统直接向系统申请动态内存,也可以通过动态内存分配器的malloc接口分配内存,而动态内存分配器会通过sbrk、mmap向系统分配内存,所以应用程序通过free释放的内存,并不一定会真正返还给系统,它也有可能被动态内存分配器缓存起来。

所以当你malloc/free配对得很好,但通过top命令去看进程的内存占用,还是很高,你不应该感到惊讶。

google有自己的动态内存分配器tcmalloc,另外jemalloc也是著名的动态内存分配器,他们有不同的性能表现,也有不同的缓存和分配策略。必要的时候,你可以用它们替换linux系统glibc自带的ptmalloc。

new/delete跟malloc/free的关系

new是c++的用法,比如Foo *f = new Foo,其实它分为3步。

  1. 通过operator new()分配sizeof(Foo)的内存,最终通过malloc分配。
  2. 在新分配的内存上构建Foo对象。
  3. 返回新构建的对象地址。

new=分配内存+构造+返回,而delete则是等于析构+free。

所以搞定malloc、free就是从根本上搞定动态内存分配。

chunk

每次通过malloc返回的一块内存叫一个chunk,动态内存分配器是这样定义的,后面我们都这样称呼。

wrap malloc

gcc支持wrap,即通过传递-Wl,--wrap,malloc的方式,可以改变调用malloc的行为,把对malloc的调用链接到自定义的__wrap_malloc(size_t)函数,而我们可以在__wrap_malloc(size_t)函数的实现中通过__real_malloc(size_t)真正分配内存,而后我们可以做搞点小动作。

同样,我们可以wrap free。

malloc跟free是配对的,当然也有其他相关API,比如calloc、realloc、valloc,这些都是细节,根本上还是malloc和free,比如realloc就是malloc + free的组合。

怎么去定位内存泄漏呢?

我们会malloc各种不同size的chunk,也就是每种不同size的chunk会有不同数量,如果我们能够跟踪每种size的chunk数量,那就可以知道哪种size的chunk在泄漏。很简单,如果该size的chunk数量一直在增长,那它很可能泄漏。

程序员的福音,C/C++内存泄漏的终极解决方案

光知道某种size的chunk泄漏了还不够,我们得知道是哪个调用路径上导致该size的chunk被分配,从而去检查是不是正确释放了。

怎么跟踪到每种size的chunk数量?

我们可以维护一个全局 unsigned int malloc_map[1024 * 1024]数组,该数组的下标就是chunk的size,malloc_map[size]的值就对应到该size的chunk分配量。

这等于维护了一个chunk size到chunk count的映射表,它足够快,而且可以覆盖到0 ~ 1M大小的chunk的范围,它已经足够大了,试想一次分配一兆的块已经很恐怖了,可以覆盖到大部分场景。

那大于1M的块怎么办呢?我们可以通过log的方式记录下来。

在__wrap_malloc里,++malloc_map[size]

在__wrap_free里,--malloc_map[size]

如此一来,我们便通过malloc_map记录了各size的chunk的分配量。

如何知道释放的chunk的size?

不对,free(void *p)只有一个参数,我如何知道释放的chunk的size呢?怎么办?

我们通过在__wrap_malloc(size_t)的时候,分配8+size的chunk,也就是额外分配8字节,用起始的8字节存储该chunk的size,然后返回的是(char*)chunk + 8,也就是偏移8个字节地址,返回给调用malloc的应用程序。

程序员的福音,C/C++内存泄漏的终极解决方案

这样在free的时候,传入参数void* p,我们把p往前移动8个字节,解引用就能得到该chunk的大小,而该大小值就是之前在__wrap_malloc的时候设置的size。

好了,我们真正做到记录各size的chunk数量了,它就存在于malloc_map[1M]的数组中,假设64个字节的chunk一直在被分配而没有被正确回收,最终会表现在malloc_map[size]数值一直在增长,我们觉得该size的chunk很有可能泄漏,那怎么定位到是哪里调用过来的呢?

如何记录调用链?

我们可以维护一个toplist数组,该数组假设有10个元素,它保存的是chunk数最大的10种size,这个很容易做到,通过对malloc_map取top 10就行。

然后我们在__wrap_malloc(size_t)里,测试该size是不是toplist之一,如果是的话,那我们通过glibc的backtrace把调用堆栈dump到log文件里去。

注意:这里不能再分配内存,所以你只能使用backtrace,而不能使用backtrace_symbols,这样你只能得到调用堆栈的符号地址,而不是符号名。

如何把符号地址转换成符号名,也就是对应到代码行呢?答案是addr2line。

addr2line

addr2line工具可以做到,你可以追查到调用链,进而定位到内存泄漏的问题。

至此,你已经get到了整个核心思想。

当然,实际项目中,我们做的更多,我们不仅仅记录了toplist size,还记录了各size chunk的增量toplist,会记录大块的malloc/free,会wrap更多的API。

总结一下:通过wrap malloc/free + backtrace + addr2line,你就可以定位到内存泄漏了。

美好的时间过得太快,又是时候说byebye!

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多
    喜欢该文的人也喜欢 更多

    ×
    ×

    ¥.00

    微信或支付宝扫码支付:

    开通即同意《个图VIP服务协议》

    全部>>