技术干货丨经过wrap malloc定位C/C++的内存泄漏问题

摘要：用C/C++开发的程序执行效率很高，但却常常受到内存泄漏的困扰。本文提供一种经过wrap malloc查找memory leak的思路。

用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，你就能够定位到内存泄漏了，恭喜你们。

点击关注，第一时间了解华为云新鲜技术~