一种定位内存泄露的方法（Solaris）

问题：

客户测试的镜像环境出现一个3.8G的core文件，查看堆栈发现是new失败了导致进程abort。因为是32位应用程序，应该是所有的heap空间都被用光了，导致new失败。

推测有几种可能：

1） 内存泄露导致内存耗尽。

2） 有些静态对象处理的不合理，导致一直在增大。

3） 有死循环，导致一直在做类似list::insert这样的操作，最终耗尽内存。

定位思路：

如果是第二种情况，则使用pstack core看到的所有堆栈中，一定有个堆栈是包含死循环的。

使用pmap core（或者在mdb中使用::mappings），看到heap空间很大，有3G多。程序里直接new内置对象(int、string等)的操作几乎没有，所以重点分析class或struct对象。而我们使用的class或struct，一般都会有虚函数表。可以使用mdb遍历所有的heap空间，将所有的指向虚函数表的指针进行统计，那个值最大的一般就是有问题（泄露或死循环）的类型，然后再搜索代码，找到出问题的地方。

动手：

使用mdb打开core文件，使用如下命令将符号导出到leaks.txt中：

$G

addr, count/apn!grep vtbl>leaks.txt

其中addr为heap开始的地址；count为重复次数，32位程序可以用size/4得到；

a为点作为符号+偏移；

p为显示符号；

n为换行。

详细见下面的例子。

第二天上班后，文件导完了，导出的leaks.txt有2.8G之巨。将其导入到SQLServer中（有4千多万条数据），然后使用group by语句，可以得到使用了最多的类型，为保存数据库里值的类型。

结论：

因为程序从启动到coredump，只用了不到两个小时的时间，出现大规模内存泄露导致耗尽的可能不大。查看所有堆栈，操作数据库的堆栈不多，很快确定有问题的堆栈。获得其参数，使用这个参数在现有代码里打桩测试，很快复现了问题。最终发现是数据库的类使用的有问题，导致笛卡尔积了。在表里数据比较少的时候不会出问题，表数据多了，就会出现内存不够用的情况。

实例：

因为core文件在公司里，我这里写了个程序模拟new失败，然后重现一下上面的定位方法：

#include <stdexcept>

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;

}

1） 编译运行此段代码。产生一个core文件

2） 用mdb打开这个core文件，运行::mappings：

mdb core

Loading modules: [ libc.so.1 ld.so.1 ]

> $G

C++ symbol demangling enabled

> ::mappings

    BASE    LIMIT     SIZE NAME

 8046000  8048000     2000 [ stack ]

 8050000  8051000     1000 /test/new_fail/a.out

 8060000  8062000     2000 /test/new_fail/a.out

 8062000  8088000    26000 [ heap ]

fecb4000 fecb5000     1000

fecc0000 fecc1000     1000

fecd0000 fed88000    b8000 /lib/libc.so.1

fed98000 fed9e000     6000 /lib/libc.so.1

fed9e000 feda0000     2000 /lib/libc.so.1

fedb0000 fedf3000    43000 /lib/libm.so.2

fee02000 fee06000     4000 /lib/libm.so.2

fee10000 fee19000     9000 /usr/lib/libCrun.so.1

fee28000 fee2a000     2000 /usr/lib/libCrun.so.1

fee2a000 fee2f000     5000 /usr/lib/libCrun.so.1

fee40000 fef54000   114000 /usr/lib/libCstd.so.1

fef63000 fefa4000    41000 /usr/lib/libCstd.so.1

fefb0000 fefb6000     6000

fefc0000 fefc1000     1000

fefc9000 fefea000    21000 /lib/ld.so.1

feffa000 feffb000     1000 /lib/ld.so.1

feffb000 feffd000     2000 /lib/ld.so.1

可以看到heap空间的地址范围是0x8062000－0x8088000，共0x26000字节。

3） 因为是32位应用程序，所以指针占4字节。所以需要遍历的指针个数为0x26000/4=0x9800。将结果输出到leaks.txt中：

> 8062000, 9800/apn!grep vtbl>leaks.txt

4） leaks.txt的内容为：

0x807a538:      libCstd.so.1`std::ctype<wchar_t>::__vtbl

0x8080628:      libCstd.so.1`std::ctype<char>::__vtbl

0x8080a90:      a.out`ABC::__vtbl

0x8080aa8:      a.out`ABC::__vtbl

0x8080ac0:      a.out`ABC::__vtbl

….

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

select Col002, count(1) quantity from leaks

group by Col002

order by quantity desc

结果为：

Col001                                                                                 quantity

a.out`ABC::__vtbl                                                           1000

libCstd.so.1`std::ctype<char>::__vtbl                    1

libCstd.so.1`std::ctype<wchar_t>::__vtbl            1

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

顶

0

踩