linux pmap 内存泄露,一个驱动导致的内存泄漏问题的分析过程(meminfo->pmap->slabtop->alloc_calls)...

关键词：sqllite、meminfo、slabinfo、alloc_calls、nand、SUnreclaim等等。

下面记录一个由于驱动导致的内存泄漏问题分析过程。

首先介绍问题背景，在一款嵌入式设备上，新使用sqllite库进行数据库操作，在操作数据(大量读写操作)一段时间之后，发生OOM现象。

然后OOM会选择进程kill，即使系统中不剩什么进程，仍然内存紧张。

下面就介绍从上往下查找问题，然后在底层掐住RootCause，进而解决问题的分析过程。

1. 问题初步分析

首先怀疑的是sqllite库问题，在PC进行同样的测试未发现内存泄漏。在另一款参考设备上，进行同样的测试，未发现内存泄漏。

以上测试确保了测试程序、sqllite库等一致，仅交叉工具链和平台不一致。

结论：可以基本肯定sqllite库以及测试程序没有问题，可能的问题包括交叉工具链、平台问题。平台问题更大，所以问题集中到具体平台上进行分析。

疑问点：

1. 为何进程退出后，泄漏的内存没有释放？参见分析，是因为SUnreclaim的slab内存不在进程内存统计范围之内。

2. 是否由于工具链不同导致库函数表现不一致？参见分析1，内存泄漏点在内核驱动中。 参见分析2，经过在RAM上运行sqllite测试；单独测试NAND文件系统，得出泄漏和sqllite无关。

3. 是平台内核导致的泄漏吗？参见分析，确定泄漏在kmalloc-4096这个slab中。

2. 具体平台查找内存泄漏方向

定位内存泄漏按照从大到小的思路，即首先看系统内存哪里泄漏，然后再看进程内存哪里泄漏，最后看哪种内存泄漏。

2.1 分析系统内存

首先通过cat /proc/meminfo，然后分析泄漏点。

从MemFree和MemAvailable看，内存将低了235M和228M。

然后看一下下面内存消耗在哪里？可以看出slab消耗了228M，再细节可以看出SUreclaim消耗了228M。基本确定