认识Kernel 内存泄漏

dumpsys meminfo 看到内核内存Used RAM中，kernel达到了800+MB，这就是内存泄漏~
[10:53:13]Total PSS by category:
[10:53:13] 276,057K: Native
[10:53:13] 78,172K: GL mtrack
[10:53:13] 63,058K: .dex mmap
[10:53:13] 56,870K: Unknown
[10:53:13] 46,834K: Dalvik
[10:53:13] 35,119K: .so mmap
[10:53:13] 34,881K: .art mmap
[10:53:13] 24,976K: Dalvik Other
[10:53:13] 18,604K: .oat mmap
[10:53:13] 9,460K: .jar mmap
[10:53:13] 7,773K: .apk mmap
[10:53:13] 7,699K: Other mmap
[10:53:13] 2,136K: Stack
[10:53:13] 1,023K: Other dev
[10:53:13] 280K: Ashmem
[10:53:13] 131K: .ttf mmap
[10:53:13] 0K: Cursor
[10:53:13] 0K: Gfx dev
[10:53:13] 0K: EGL mtrack
[10:53:13] 0K: Other mtrack
[10:53:13]
[10:53:13]Total RAM: 2,038,688K (status normal)
[10:53:13] Free RAM: 555,318K ( 105,538K cached pss + 327,000K cached kernel + 122,780K free)
[10:53:13] Used RAM: 1,451,497K ( 626,861K used pss + 824,636K kernel)
[10:53:13] Lost RAM: 24,665K
[10:53:13] ZRAM: 19,464K physical used for 78,176K in swap ( 511,996K total swap)
[10:53:13] Tuning: 192 (large 512), oom 184,320K, restore limit 61,440K (high-end-gfx)
对比看下P212版本正常的 Used RAM: 758,045K ( 576,505K used pss + 181,540K kernel)

再看内核里面init_pic_list已经有500MB了，这是播放H265视频时内核对应的函数栈
cat /proc/pagetrace
[10:53:36]Node 0, zone DMA
[10:53:36]count(KB) kaddr function
[10:53:36]------------------------------
[10:53:36] 529160, ffffff8001f84078, init_pic_list [amvdec_h265]
[10:53:36] 117856, ffffff80020ae8e8, kbase_mem_alloc_page [mali_kbase]
[10:53:36] 41420, ffffff800909e8e8, copy_process.isra.68.part.69
[10:53:36] 25380, ffffff8009784864, ion_page_pool_alloc
[10:53:36] 20968, ffffff80091dec40, __pte_alloc
[10:53:36] 9548, ffffff80091e1f0c, handle_mm_fault
[10:53:36] 6592, ffffff8009a151cc, __kmalloc_reserve.isra.48
[10:53:36] 5392, ffffff8009094350, module_alloc
[10:53:36] 4352, ffffff8001d01640, firmware_pre_load [firmware]
[10:53:36] 3476, ffffff80093ec7a8, selinux_inode_alloc_security
[10:53:36] 3204, ffffff80091e80b4, mmap_region
[10:53:36] 3028, ffffff80092983ec, __kernfs_new_node
[10:53:36] 2856, ffffff80091ec3dc, anon_vma_fork
[10:53:36] 2612, ffffff80091e5fd8, __split_vma.isra.41

echo m > proc/sysrq-trigger
p212:/ # echo m > proc/sysrq-trigger
[46376.695948@1] sysrq: SysRq : Show Memory
[46376.696065@2] Mem-Info:
[46376.696720@2] active_anon:77726 inactive_anon:155 isolated_anon:0
[46376.696720@2] active_file:60437 inactive_file:129125 isolated_file:0
[46376.696720@2] unevictable:63 dirty:0 writeback:0 unstable:0
[46376.696720@2] slab_reclaimable:9932 slab_unreclaimable:12665
[46376.696720@2] mapped:66913 shmem:253 pagetables:5866 bounce:0
[46376.696720@2] [cma] driver:14173 anon:22650 file:68189 isolate:0 total:128000
[46376.696720@2] free:156313 free_pcp:426 free_cma:22834
[46376.738875@2] Node 0 active_anon:310904kB inactive_anon:620kB active_file:241748kB inactive_file:516500kB unevictable:252kB isolated(anon):0kB isolated(file):0kB mapped:267652kB dirty:0kB writeback:0kB shmem:1012kB writeback_tmp:0kB unstable:0kB pages_scanned:0 all_unreclaimable? no
[46376.763567@2] DMA free:625248kB min:4928kB low:35492kB high:66056kB active_anon:310904kB inactive_anon:620kB active_file:241748kB inactive_file:516500kB unevictable:252kB writepending:0kB present:2096128kB managed:2037652kB mlocked:256kB slab_reclaimable:39728kB slab_unreclaimable:50660kB kernel_stack:16896kB pagetables:23464kB bounce:0kB free_pcp:1704kB local_pcp:364kB free_unmovable:31120kB free_movable:501588kB free_reclaimable:1144kB free_highatomic:0kB free_isolate:0kB free_cma:91324kB
[46376.806588@2] lowmem_reserve[]: 0 0 0
[46376.810016@2] DMA: 5476*4kB (UMEC) 2278*8kB (UMEC) 997*16kB (UMEC) 546*32kB (UMEC) 343*64kB (UMC) 156*128kB (UMC) 81*256kB (UMC) 25*512kB (UMC) 25*1024kB (UMEC) 20*2048kB (UMC) 100*4096kB (MC) = 625168kB
189806 total pagecache pages
[46376.830543@2] 0 pages in swap cache
[46376.834025@2] Swap cache stats: add 0, delete 0, find 0/0
[46376.839417@2] Free swap = 511996kB
[46376.842817@2] Total swap = 511996kB
[46376.846274@2] 524032 pages RAM
[46376.849285@2] 0 pages HighMem/MovableOnly
[46376.853256@2] 14619 pages reserved

[46376.856603@2] 128000 pages cma reserved

最后的修改：

new_buf = krealloc(pic->aux_data_buf,
new_size,
GFP_KERNEL);

----->
new_buf = vmalloc(new_size);
memcpy(new_buf, pic->aux_data_buf, pic->aux_data_size);
if (pic->aux_data_buf)

vfree(pic->aux_data_buf);

if (pbi->fw)
vfree(pbi->fw);
pbi->fw = NULL;

认识Kernel 内存泄漏相关推荐

内存泄漏排查攻略之：Show me your Memory
以下文章来源方志朋的博客,回复"666"获面试宝典来源| cnblogs.com/yougewe/p/11334342.html java 语言有个神奇的地方,那就是你时不时会去 ...
linux工具之检测内存泄漏-valgrind
0.前言内存泄漏是c++程序常见的问题了,特别是服务类程序,当系统模块过多或者逻辑复杂后,很难通过代码看出内存泄漏: valgrind是一个开源的,检测c++程序内存泄漏有效工具,编译时加上-g选项 ...
Kaldi内存泄漏问题排查
转载自:https://www.baidu.com/link?url=uUnBEi2XoXwkMYf_mLzKuZmdz8auQ5mjvwYE0c5zsKS2kUcEMv3fo9wUmva2S84mX ...
18 | 案例篇：内存泄漏了，我该如何定位和处理？
通过前几节对内存基础的学习,我相信你对 Linux 内存的工作原理,已经有了初步了解. 对普通进程来说,能看到的其实是内核提供的虚拟内存,这些虚拟内存还需要通过页表,由系统映射为物理当进程通过 ma ...
如何自动检查内存泄漏和句柄耗尽
如何自动检查内存泄漏和句柄耗尽 1. 背景当程序的子模块数量和规模扩大之后,在开发阶段,系统长时间允许后经常会碰到下面一些bug: 内存泄漏.随着时间允许,系统可用的内存越来越少,最后kernel ...
【Linux进程、线程、任务调度】一 Linux进程生命周期僵尸进程的含义停止状态与作业控制内存泄漏的真实含义 task_struct以及task_struct之间的关系
学习交流加(可免费帮忙下载CSDN资源): 个人微信: liu1126137994 学习交流资源分享qq群1(已满): 962535112 学习交流资源分享qq群2: 780902027 文章目录 1 ...
AliOS Things 维测典型案例分析 —— 内存泄漏
维测典型案例分析1 -- 内存泄漏在系统运行的过程中,内存泄漏是较为常见但是很难复现的现象,一般的内存泄漏点都是比较隐蔽的,每次几十个字节的泄漏,往往需要压测很久才能复现问题.本节案例分析,我们从一 ...
linux pmap 内存泄露,一个驱动导致的内存泄漏问题的分析过程(meminfo-pmap-slabtop-alloc_calls)...
关键词:sqllite.meminfo.slabinfo.alloc_calls.nand.SUnreclaim等等. 下面记录一个由于驱动导致的内存泄漏问题分析过程. 首先介绍问题背景,在一款嵌入式 ...
【华为云技术分享】技术干货丨通过wrap malloc定位C/C++的内存泄漏问题
摘要:用C/C++开发的程序执行效率很高,但却经常受到内存泄漏的困扰.本文提供一种通过wrap malloc查找memory leak的思路. 用C/C++开发的程序执行效率很高,但却经常受到内存泄漏 ...

认识Kernel 内存泄漏

认识Kernel 内存泄漏相关推荐

最新文章

热门文章