# 内存泄漏-ion(KERNEL_MEMORY)问题排查

#### 问题现象

应用在使用过程中出现闪退，hilog日志中PROCESS\_KILL的Reason为ResourceLeak:ION Leak，memory\_leak中生成memleak-kernel-\[process\_name\]-0-sample和memleak-kernel-\[process\_name\]-0-\[timestamp\]的内存泄漏日志文件。

#### 背景知识

*   ION泄漏的检测机制同ashmem泄漏相似，通过内核监控整机ION内存，当触发泄漏管控时，系统会对使用ION内存最多的应用进行终止。
*   应用被管控后，会在/data/log/memory\_leak/目录生成两个故障日志文件以供分析：
    *   memleak-native-\[process\_name\]-\[pid\]-0-sample.txt：采样日志文件，用于观察内存增长趋势，确认泄漏情况。
    *   memleak-native-\[process\_name\]-\[pid\]-0-\[timestamp\].txt：维测日志文件，记录了一些内存相关的统计信息，用于不同泄漏问题的维测。

*   DevEco Profiler提供了基础的内存场景分析Allocation，可以使用Allocation来分析应用或元服务在运行时的内存分配及使用情况，识别和定位内存泄漏、内存抖动以及内存溢出等问题，对应用或元服务的内存使用进行优化，参考文档内存分析介绍。

#### 问题定位

应用进程触发ION泄漏的管控后，系统会抓取泄漏相关的信息，在memory\_leak目录生成两个故障日志文件以供分析。

**步骤一：分析采样日志memleak-native-\[process\_name\]-\[pid\]-sample.txt。**

排查ION内存增长情况，是否超过了hardThreshold，或是超过softThreshold长时间未下降。

日志如下：

```
memoryName:ion
softThreshold:3000(MB)	<- 进程软门限
hardThreshold:4500(MB)	<- 进程硬门限
topMemory:4801960(KB)	<- ION内存峰值

               time(s)      kernelMemory(KB)    realtime
// ...
22              13434           1019272         2026/01/07 22:17:14
23              13654           1015092         2026/01/07 22:20:54
24              13874           1887776         2026/01/07 22:24:34
25              14094           3098152         2026/01/07 22:28:14
26              14314           3562252         2026/01/07 22:31:54
27              14534           4597952         2026/01/07 22:35:34
28              14754           4801960         2026/01/07 22:39:14
```

**步骤二：分析维测日志memleak-native-\[process\_name\]-\[pid\]-0-\[timestamp\]。**

日志规格如下：

```
Generated by HiviewDFX @OpenHarmony
LOGGER_MEMCHECK_GERNAL_INFO
memoryName:ion
softThreshold:3000(MB)
hardThreshold:4500(MB)
appHardThreshold:5460(MB)
topMemory:4801960(KB)

*****************************
LOGGER_MEMCHECK_MEMINFO		<- 整机内存统计信息
MemTotal:       15815588 kB
IonTotalUsed:    4843976 kB
GpuTotalUsed:     264056 kB
AshmemUsed:       214599 kB
************ endl ************

*****************************
LOGGER_MEMCHECK_PROC_INFO	<- ashmem/ion/gpu对应泄漏内存节点信息打印(泄漏类型不同，落盘的内存信息不同)
MM_DMABUF_INFO
realtime:	2026/01/07 22:39:14
Process       	pid	fd    size_bytes ino   exp_pid	exp_task_comm	buf_name	                        exp_name	buf_type        leak_type
com.hx.example	4969	285	61440	 56492	45101	allocator_host	120x120-re*ou*ce*33*51*15*8.*ng       mm_heap_helpers	pixelmap	pixelmap
com.hx.example	4969	291	8192	 55773	1423	allocator_host	srcImageSize-28x29-pixelMapSize...    mm_heap_helpers	pixelmap	pixelmap
com.hx.example	4969	488	28528640 79496	55590	allocator_host	4969                                  mm_heap_helpers   xcomponent	xcomponent-t-AP_7682cbcf-8689-4e67-aa34-515d2852e187
com.hx.example	4969	555	4096	 57372	1423	allocator_host	4969                                  mm_heap_helpers	NULL            external
com.hx.example	4969	710	3534848	 76954	56996	allocator_host	id:lynx-400929851264-monitor-image    mm_heap_helpers	pixelmap	pixelmap
com.hx.example	4969	779	1474560	 72141	37535	av_codec_servic	720x1280-hevc-394                     mm_heap_helpers	NULL	        hw-video-decoder
 // ...
************ endl ************
```

*   从LOGGER\_MEMCHECK\_MEMINFO整机内存统计信息中排查使用情况IonTotalUsed。
*   从LOGGER\_MEMCHECK\_PROC\_INFO泄漏内存节点信息的MM\_DMABUF\_INFO中，排查相同内存块size\_bytes的大小和数量，总内存的占比是否过大，并结合buf\_name和leak\_type分析使用场景是否合理，具体含义可见ION泄漏第五点。

**步骤三：结合业务代码分析泄漏点。**

*   排查方向：
    *   视频软硬编解码器API接口使用不当。
    *   XComponent组件泄漏或者缓存过多。
    *   使用Surface的NDK接口分配内存，没有释放。
    *   ArkWeb控件泄漏。
    *   Image控件泄漏或者缓存过多。

#### 分析结论

应用存在ION泄漏，存在使用后的资源未释放。

#### 修改建议

程序需要正确管理分配的资源，使用完毕后需立刻释放。常见泄漏问题修复方法可见资源泄漏类问题优化建议和资源泄漏类问题案例。