GDB调试和NATIVE内存问题分析整理

前段时间分析了一个疑似内存泄露的问题，自己总结下。

 

1.  当出现很大size的内存泄露的时候，一般情况下都是native的，很有可能会发生OOM导致的NE。

2.  怀疑是内存泄露的时候，可以通过while脚本隔几秒打印一次procrank来确定，如果某个PID的PSS/USS 一直在上升，那么狠有可能就是他了。

3. 当定位到某个PID之后，可以每隔一段时间将其 /proc/pid/mmaps倒出来，比较增长的区间，一般情况下，都可以看到对应的库，定位到SO之后就好办了，重新导入打开debug的lic，复现之后，就可以得到malloc的入口地址，再通过link工具找出对应的文件地址就好了。

4. 如果当前的区域是匿名的，也就是该段内存是通过映射匿名共享内存得到的，即用mmap2，且传入的参数为PRIVATE/ANYMOSXXX 。碰到这种问题的时候，GDB就派上用场了。

5. GDB连上PID后，在mmap2打上断点，当出现mmap事件停住的时候，注意看下获取到的新的堆的顶指针地址，再加上offset，记下来。同时，导出/proc/pid/mmaps，查看增长区间的堆的地址，如果符合，那么凶手就是mmap动作的发起者。