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

#### 问题现象

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

#### 背景知识

*   ashmem（匿名共享内存）泄漏是指调用了申请ashmem内存接口后，由于疏忽或错误未能及时释放，导致ashmem内存持续累积，对整机运行造成影响。
*   ashmem泄漏的检测机制是通过内核监控整机ashmem内存是否超过阈值，当触发泄漏管控时，系统会对使用ashmem内存最多的应用进行终止。
*   应用被管控后，会在/data/log/memory\_leak/目录生成两个故障日志文件以供分析：
    *   memleak-native-\[process\_name\]-\[pid\]-0-sample.txt：采样日志文件，用于观察内存增长趋势，确认泄漏情况。
    *   memleak-native-\[process\_name\]-\[pid\]-0-\[timestamp\].txt：维测日志文件，记录了一些内存相关的统计信息，用于不同泄漏问题的维测。

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

#### 问题定位

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

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

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

日志如下：

```
memoryName:ashmem
softThreshold:2048(MB)	<- 进程软门限
hardThreshold:4096(MB)	<- 进程硬门限
topMemory:3387703(KB)	<- ashmem内存峰值

              time(s)       kernelMemory(KB)         realtime
0               219             310903          2026/01/06 18:24:21
1               439             1321613         2026/01/06 18:28:01
2               659             1307039         2026/01/06 18:31:41
3               879             1377038         2026/01/06 18:35:21
4               1099            1374640         2026/01/06 18:39:01
5               1319            1369825         2026/01/06 18:42:41
6               1539            1363453         2026/01/06 18:46:21
7               1759            1364565         2026/01/06 18:50:01
8               1979            1299033         2026/01/06 18:53:41
9               2199            1299033         2026/01/06 18:57:21
10              2419            1930830         2026/01/06 19:01:01
11              2639            2017218         2026/01/06 19:04:41
12              2859            1875315         2026/01/06 19:08:29
13              3079            3322171         2026/01/06 19:12:09
14              3299            3387703         2026/01/06 19:15:49
15              3519            3387703         2026/01/06 19:19:29
16              3739            3387703         2026/01/06 19:23:09
17              3959            3367434         2026/01/06 20:06:46
18              4179            3325124         2026/01/06 20:45:02
19              4399            3338757         2026/01/06 20:48:42
20              4619            3340933         2026/01/06 21:00:05
```

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

日志规格如下：

```
Generated by HiviewDFX @OpenHarmony
LOGGER_MEMCHECK_GERNAL_INFO
memoryName:ashmem
softThreshold:2048(MB)
hardThreshold:4096(MB)
appHardThreshold:5460(MB)
topMemory:3387703(KB)

*****************************
LOGGER_MEMCHECK_MEMINFO		<- 整机内存统计信息
MemTotal:       15815588 kB
IonTotalUsed:     559284 kB
GpuTotalUsed:      48576 kB
AshmemUsed:      3340933 kB
************ endl ************

*****************************
LOGGER_MEMCHECK_PROC_INFO	<- ashmem/ion/gpu对应泄漏内存节点信息打印(泄漏类型不同，落盘的内存信息不同)
ASHMEM_PROCESS_INFO
realtime:	2026/01/06 21:00:05
Process ashmem overview info:	<- 所有进程ashmem概览信息
---------------------------------------------------------------------------------
Process_name Virtual_size Physical_size
Total ashmem  of [render_service] virtual size is  2568215348, physical size is 1387921408 
Total ashmem  of [com.hx.example] virtual size is  3099027904, physical size is 1609773056 
// ...
Process ashmem detail info:		<- 进程ashmem详细信息
---------------------------------------------------------------------------------
Process_name  Process_ID  Fd   Cnode_idx Applicant_Pid	Ashmem_name                Virtual_size  Physical_size magic
com.hx.example	19062	  252	328421	  19062	        dev/ashmem/shared_memory/E...	4096	  0	       12188
com.hx.example	19062	  291	328421	  1388	        dev/ashmem/gralloc_shared_attr	4096	  4096	       12161
com.hx.example	19062	  271	328421	  19062	        dev/ashmem/Create PixelMap	11059200  11059200     31305
com.hx.example	19062	  317	328421	  19062	        dev/ashmem/Create PixelMap	3686400	  0	       12830
// ...
---------------------------------------------------------------------------------

************ endl ************
```

*   从LOGGER\_MEMCHECK\_MEMINFO整机内存统计信息中排查使用情况AshmemUsed。
*   从LOGGER\_MEMCHECK\_PROC\_INFO泄漏内存节点信息的overview概览中，排查应用进程的virtual size是否占比较大。
*   在Process ashmem detail info进程ashmem详细信息中，找到Process\_name为应用进程的数据，排查相同Ashmem\_name出现次数最多的Virtual\_size内存块，可能存在泄漏点。

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

排查方向：

*   如使用了Node-API在native层创建并使用decode()解码获取PixelMap，需排查申请未释放、把PixelMap缓存到应用生命周期的容器类中、对象引用计数变量多加等可能。相关接口文档可见C API，排查使用后是否调用OH\_XXX\_Release()对应接口释放资源。
*   如使用了JS层的PixelMap，需排查JS对象泄漏或者缓存太多导致PixelMap大量占用，可使用DevEco Studio中的profiler工具抓取两次snapshot，分析对象的增量。相关接口文档可见ArkTS API，排查使用后是否调用Release()对应接口释放资源。
*   pixmap使用的ashmem内存，应用可自定义绑定pixmap名字，当出现ashmem泄漏，快速根据ashmem块的名字锁定哪张图片存在问题，反推至对应的问题组件。JS层API：setMemoryNameSync，NATIVE层API：OH\_PixelmapNative\_SetMemoryName()。

#### 分析结论

应用存在ashmem泄漏，使用了PixelMap对象未释放。

#### 修改建议

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