一种定位内存泄露的方法（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

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 ::__vtbl

0x8080628: libCstd.so.1`std::ctype ::__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 ::__vtbl 1

libCstd.so.1`std::ctype ::__vtbl 1

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

本文来自优快云博客，转载请标明出处：http://blog.youkuaiyun.com/lw1a2/archive/2010/05/15/5594801.aspx