如何通过wrap malloc定位C/C++的内存泄漏问题

时间:2022-03-02 11:22:43

前言

用C/C++开发的程序执行效率很高,但却经常受到内存泄漏的困扰。本文提供一种通过wrap malloc查找memory leak的思路,依靠这个方法,笔者紧急解决了内存泄漏问题,避免项目流血上大促,该方法在日后工作中大放光彩,发现了项目中大量沉疴已久的内存泄漏问题。

什么是内存泄漏?

动态申请的内存丢失引用,造成没有办法回收它(我知道杠jing要说进程退出前系统会统一回收),这便是内存泄漏。

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

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

怎么查内存泄漏?

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

所以,我们需要借助工具,比如valgrind,但这些找内存泄漏的工具,往往对你使用动态内存的方式有某种期待,或者说约束,比如常驻内存的对象会被误报出来,然后真正有用的信息会掩盖在误报的汪洋大海里。很多时候,甚至valgrind根本解决不了日常项目中的问题。

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

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

什么是动态内存分配器?

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

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

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

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数量一直在增长,那它很可能泄漏。

光知道某种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的应用程序。

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

好了,我们真正做到记录各size的chunk数量了,它就存在于malloc_map[1M]的数组中,假设64个字节的chunk一直在被分配,数量一直在增长,我们觉得该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工具可以做到,你可以追查到调用链,进而定位到内存泄漏的问题。

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

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

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

以上就是如何通过wrap malloc定位C/C++的内存泄漏问题的详细内容,更多关于wrap malloc定位C/C++的内存泄漏的资料请关注服务器之家其它相关文章!

原文链接:https://www.cnblogs.com/huaweiyun/p/13278383.html