linux内存泄漏通用排查方法

一．   概述

Linux下经常遇到内存泄漏的问题，尤其对C/C++开发人员来说是一个亘古不变的话题，现在介绍解决Linux内存泄漏问题的方法层出不穷，让人眼花缭乱，但是作为开发人员应该从本质上了解为何会发生内存泄漏，在面对内存泄漏的问题时应当知道相关的技术细节，在解决问题时应当有个固定的排查思路，要善用Linux系统本身提供的工具来定位和解决，而不是一味的通过各种各样不常用的、不熟悉的工具来排查问题，这样不仅耗时，最终不一定能够解决问题。

本文力求通过一种通用的方法来讲解如何在Linux下定位和解决内存泄漏问题。

关键字：Linux 内存泄漏 GDB

二．   内存分析

内存发生泄漏是因为我们的程序通过大量的malloc或者new操作来申请内存的后，没有及时或者根本没有释放内存导致的，那么程序通过malloc或者new操作到底申请了什么内存？如何判断程序发生了内存泄漏？这里要对Linux下的进程内存模型做个介绍。

                                          (图片引自CSDN)

如上图，操作系统加载进程执行后，系统内核通过进程控制块来管理进程，进程控制块里有专门的内存管理模块（其实是一个结构体struct_mm）标记并管理进程不同内存区域内的内存段。需要注意的是程序运行过程中，CPU对内存的操作都是通过逻辑地址进行的，内存管理单元（MMU）将逻辑地址映射成真正的物理地址从而实现对内存的读写，因此在我们程序调试的过程中出现的地址都是逻辑地址，逻辑地址在编译阶段就已经确定！！！

操作系统加载程序到逻辑地址的映射整个过程对开发人员来说都是透明的，开发人员无需关心。

程序运行过程中如果调用malloc和new等libc接口来动态申请内存时，malloc和new接口最终调用sys_brk系统接口通过移动mm_struct结构体里的brk指针来实现虚拟内存的申请和释放，同时操作系统会完成物理内存的分配和虚拟地址到物理地址的映射，过程如下。

 

                                                 (图片引自CSDN)

因此可以得出结论: 通过观察进程虚拟内存占用大小和变化就可以判断出内存是否发生泄漏，这里使用常见的top命令就能够得到进行的虚拟内存相关信息，VIRT列就是虚拟内存大小，关于top命令的使用和详细解释请自行百度。

三．   问题排查

上面对内存做了基本的介绍，下面通过一个实例来介绍如何解决内存泄露的问题。

       以x86架构为例，Linux系统里，进行动态申请内存时如果物理内存足够，操作系统是不会停止并转储进程的，开发人员可以通过设置进程虚拟内存大小的阈值使进程自行产生DUMP，这么做也符合现场程序发生内存泄漏的一般情景，因为通常情况下我们是不知道进程发生了内存泄漏，程序往往因内存泄漏达到一定值时在当前目录下产生了DUMP文件，我们一般是去分析这些DUMP文件来定位解决问题的。

因此建议开发人员在部署程序时给程序设定一个limit 值。

ulimit -c unlimited 此命令使程序在无法申请到内存时产生CORE文件。

ulimit -c 1024 设置具体值，当程序虚拟内存达到此大小时会产生CORE文件。

有关ulimit 具体命令请自行百度

下面模拟一段内存泄漏的代码

#include<iostream>

#include<stdexcept>

using namespace std;

class ABC

{

public:

         virtual ~ABC()

         {

         }

         int i;

         int j;

};

void f()

{

         for (int i = 0; i < 1000; ++i)

         {

                   ABC* p = new ABC;

         }

         throw std::bad_alloc();

}

int main()

{

         f();

         return 0;

}

函数f()会申请1000次对象 ABC，申请完后抛出异常，程序产生DUMP，我们来分析这个DUMP，这里只用linux下调试的标准工具GDB来分析这个DUMP。

1）用gdb打开这个core文件：

gdb a.out core

(gdb) run

Starting program: /test/new_fail/a.out

terminate called after throwing an instance of 'std::bad_alloc'

  what():  std::bad_alloc

 

Program received signal SIGABRT, Aborted.

0x00007ffff733f645 in raise () from /lib64/libc.so.6

(gdb) info proc

process 10683

cmdline = '/test/new_fail/a.out'

cwd = '/test/new_fail'

exe = '/test/new_fail/a.out'

(gdb) shell pmap 10683

10683: a.out

START               SIZE     RSS     PSS   DIRTY    SWAP PERM MAPPING

0000000000400000      4K      4K      4K      0K      0K r-xp /test/new_fail/a.out

0000000000600000      4K      4K      4K      4K      0K r--p /test/new_fail/a.out

0000000000601000      4K      4K      4K      4K      0K rw-p /test/new_fail/a.out

0000000000602000    132K     32K     32K     32K      0K rw-p [heap]

…（略）

Total:            11468K   1048K    684K    180K      0K

 

360K writable-private, 11108K readonly-private, 0K shared, and 1048K referenced

 

可以看到heap空间的起始地址是0x0000000000602000，共132K字节，即132*1024=135168字节。

2） 因为是64位应用程序，所以指针占8字节。所以需要遍历的指针个数为135168/8=16896。

3） 将结果输出到日志文件gdb.txt中：

(gdb) set height 0

(gdb) set logging on

Copying output to gdb.txt.

(gdb) x/16896a 0x0000000000602000

gdb.txt的内容：

0x602000:       0x0     0x21

0x602010:       0x400b30 <_ZTV3ABC+16>  0x0

0x602020:       0x0     0x21

0x602030:       0x400b30 <_ZTV3ABC+16>  0x0

….

4） 过滤gdb.txt：

awk '{print $2"/n"$3}' gdb.txt|c++filt|grep vtable>gdb_vtable.txt

gdb_vtable.txt的内容为：

<vtable for ABC+16>

<vtable for ABC+16>

<vtable for ABC+16>

<vtable for ABC+16>

….

5） 将gdb_vtable.txt的内容导入到SQLServer中（如果记录不多，可以用Excel代替）。表名为gdb_vtable，第一列Col001为符号。对其分组求和：

select Col001, count(1) quantity from gdb_vtable

group by Col001

order by quantity desc

结果为：

Col001                                                                                    quantity

<vtable for ABC+16>                                                              1000

<vtable for std::bad_alloc@@GLIBCXX_3.4+16>                    1

可知core里有1000个ABC，遍历使用ABC的代码，可知存在泄漏。

上述第五步使用SQLServer是为了对gdb_vtable.txt里的内容进行排序，以便找出被申请次数明显较多的数据，当然可以采取其他方式进行统计，比如写个脚本做统计，更进一步的，可以考虑将整个过程通过脚本自动化，这样只要执行脚本就可以将内存泄漏问题定位，一举两得。