做微网站那pc端显示啥,常州 网站建设,邳州微网站开发,用群晖如何做公司网站关键词#xff1a;sqllite、meminfo、slabinfo、alloc_calls、nand、SUnreclaim等等。下面记录一个由于驱动导致的内存泄漏问题分析过程。首先介绍问题背景#xff0c;在一款嵌入式设备上#xff0c;新使用sqllite库进行数据库操作#xff0c;在操作数据(大量读写操作)一段…关键词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。基本确定结论确定由于Unreclaim类型的slab泄漏导致的内存泄漏。疑问点找出具体哪个slab泄漏了参见分析在kmalloc-4096这个slab中。 哪个调用的slab申请参见分析通过kmalloc-4096的alloc_calls可以知道调用点。2.2 分析进程内存通过pmap -X -p pidof xxx来获取进程的地址映射空间可以分析进程内存细节。结论通过下面的对比可以看出进程本身没有导致内存泄漏。所以内存泄漏虽然有此进程导致但是泄漏点不在进程中。2.3 分析slab内存泄漏点既然确定slab导致的泄漏那么就需要使用slabtop、/proc/slabinfo以及/sys/kernel/slab来分析。从下面可以看出泄漏点在kmalloc-4096这个slab这个slab消耗的内存为250M左右。然后就是去找slab的调用记录幸运的是系统在/sys/kernel/slab/*/中提供了alloc_calls和free_calls。alloc_calls:1 pidmap_init0x4e/0x10c age418000 pid01 con_init0xf6/0x21c age418007 pid01 pcpu_mem_zalloc0x36/0x74 age417641 pid11 seq_buf_alloc0x26/0x54 age0 pid3491 register_leaf_sysctl_tables0x74/0x1b0 age418000 pid01 ubifs_mount0x68/0x15e8 age416589 pid11 ubifs_mount0xdaa/0x15e8 age416588 pid11 nand_scan_tail0xa2/0x6a8 age417469 pid11 ubi_attach_mtd_dev0x9a/0xc38 age417168 pid11 sourcesink_bind0x382/0x4c0 age417588 pid11 vid_dev_probe0x32/0x1a0 age417569 pid12 hantrodec_probe0x56/0x944 age417502/417512/417523 pid155898 spinand_cmdfunc0x236/0x52c age8997/225988/416514 pid1-202 1 flow_cache_cpu_prepare.isra.70x3c/0x74 age417889 pid1free_calls:55840 age343019 pid059 kvfree0x2a/0x60 age0/239003/415431 pid140-3491 ubifs_read_superblock0x690/0xe14 age416600 pid18 kobject_uevent_env0xda/0x580 age416605/417396/417653 pid13 uevent_show0x5e/0xf4 age409638/411302/413798 pid143-1501 skb_free_head0x2c/0x6c age417902 pid1结论从alloc_calls可以看出spinand_cmdfunc中申请了55898次slab和系统内存泄漏量基本一致。2.4 分析驱动内存泄漏通过objdump -S -l -D vmlinux vmlinux.txt然后结合反汇编代码找到spinand_cmdfunc0x236可以找到具体点。805829e2: e3f26433 bsr 0x803cf248 //803cf248 _end805829e6: c4004820 lsli r0, r0, 0spinand_cmdfunc():/home/al/deepeye1000/linux/drivers/staging/mt29f_spinand/mt29f_spinand.c:806spinand_program_page(info-spi, state-row, state-col,所以问题最终指向了mt29f_spinand.c的806行spinand_program_page()这个函数里面。分析此驱动代码可以看出通过devm_kzalloc()申请的内存没有被释放的点。虽然此内存在模块卸载的时候会被自动释放但是NAND驱动一般不会被卸载。结论确定泄漏点在spinand_program_page()中。3. 旁证测试基本上找到的问题点为了验证上述分析做了几个简单的测试。3.1 在ramfs中进行sqllite数据库操作既然泄漏点在NAND驱动中那么避开在NAND中进行读写操作即可。在/tmp目录下进行数据库操作作为对比测试。同样的软件和平台下运行同样的业务。结论在ramfs中进行操作没有发生内存泄漏。说明泄漏sqllite操作无关。。3.2 在NAND上进行文件cp、rm等操作既然泄漏点在NAND那么不使用数据库读写纯文件系统读写如何呢经过测试同样发现SUreclaim内存增加导致的泄漏。结论内存泄漏跟NAND上文件操作有关。为什么之前没有发现内存泄漏问题呢原来主要业务是运行应用很少对NAND进行写即使有写也是偶尔的发现不了内存泄漏。这种情况在频繁的读写、删除操作下比较容易复现。4. 解决问题解决的思路就是确保在函数退出的时候保证wbuf的内存能够得到释放。diff--git a/drivers/staging/mt29f_spinand/mt29f_spinand.c b/drivers/staging/mt29f_spinand/mt29f_spinand.cindex 2474d88..7042934 100644--- a/drivers/staging/mt29f_spinand/mt29f_spinand.c b/drivers/staging/mt29f_spinand/mt29f_spinand.c-495,7 495,8 static int spinand_program_page(struct spi_device *spi_nand,#ifdef CONFIG_MTD_SPINAND_ONDIEECCunsignedinti, j;- wbuf devm_kzalloc(spi_nand-dev, CACHE_BUF, GFP_KERNEL); wbuf kzalloc(CACHE_BUF, GFP_KERNEL);if (!wbuf)return -ENOMEM;-509,7 510,7 static int spinand_program_page(struct spi_device *spi_nand,retvalspinand_enable_ecc(spi_nand);if (retval 0) {dev_err(spi_nand-dev, enable ecc failed!!);- return retval; gotoexit;}}#else...-- return 0;exit:#ifdef CONFIG_MTD_SPINAND_ONDIEECC kfree(wbuf);#endif returnretval;}5. 验证测试基于以上的分析过程构建测试用例1. 进行同样的NAND上sqllite数据操作2. 同样重复cp、rm操作NAND上文件系统
