内存泄漏-gpu/gpu_rs(KERNEL_MEMORY)问题排查

问题现象

应用在使用过程中出现闪退，hilog日志中PROCESS_KILL的Reason为ResourceLeak:Gpu Leak或RENDER_MEMORY_OVER_ERROR，memory_leak目录中生成memleak-kernel-[process_name]-0-sample和memleak-kernel-[process_name]-0-[timestamp]的内存泄漏日志文件。

背景知识

gpu泄漏是指在应用运行过程中，未能及时释放gpu内存资源，导致内存持续占用且无法被回收。
gpu_rs内存泄漏与gpu泄漏的区别在于：gpu是应用自渲染发生的泄漏，gpu_rs是通过进程render_service进行统一渲染发生的泄漏。
gpu泄漏的检测机制是通过内核监控整机节点信息，当gpu内存使用量超过软门限8个采样周期或直接超过硬门限，就会判定泄漏，触发对应用的管控。
应用如果通过render_service进行统一渲染（直接向renderservice发送绘制指令），那么会在render_service中申请gpu内存，如果单个应用通过RS申请的gpu内存超过2G，那么会触发RS进程对应用的管控RENDER_MEMORY_OVER_ERROR，同步会通过泄漏检测模块上报资源泄漏事件GPU_RS。
应用被管控后，会在“/data/log/memory_leak/”目录生成两个故障日志文件以供分析：
- memleak-native-[process_name]-[pid]-0-sample.txt：采样日志文件，用于观察内存增长趋势，确认泄漏情况。
- memleak-native-[process_name]-[pid]-0-[timestamp].txt：维测日志文件，记录了一些内存相关的统计信息，用于不同泄漏问题的维测。
DevEco Profiler提供了基础的内存场景分析Allocation，可以使用Allocation来分析应用或元服务在运行时的内存分配及使用情况，识别和定位内存泄漏、内存抖动以及内存溢出等问题，对应用或元服务的内存使用进行优化，参考文档内存分析介绍。

问题定位

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

分析采样日志memleak-native-[process_name]-[pid]-sample.txt。

排查内存增长情况，是否超过了hardThreshold门限，或是超过softThreshold门限8个检测周期未下降。

日志如下：

memoryName:gpu
softThreshold:2300(MB)
hardThreshold:3450(MB)
topMemory:2750912(KB)

time(s) kernelMemory(KB)realtime
// ...
20              82987           1544200         2026/01/21 09:37:33
21              83208           2546040         2026/01/21 09:41:13
22              83428           2540460         2026/01/21 09:44:53
23              83648           2750912         2026/01/21 09:48:45
24              83868           2494756         2026/01/21 09:52:25
25              84088           2650208         2026/01/21 09:56:05
26              84308           2484484         2026/01/21 10:03:42
27              84528           2497212         2026/01/21 10:07:22
28              84748           2643384         2026/01/21 10:11:12

分析维测日志memleak-native-[process_name]-[pid]-0-[timestamp]

日志规格主要为头部通用信息、整机内存概览信息、内存节点信息和RS进程的内存使用情况。

Generated by HiviewDFX @OpenHarmony
LOGGER_MEMCHECK_GERNAL_INFO		<- 头部通用信息
memoryName:[gpu/gpu_rs]
softThreshold:2300(MB)
hardThreshold:3450(MB)
appHardThreshold:4096(MB)
topMemory:2750912(KB)

*****************************
LOGGER_MEMCHECK_MEMINFO		<- 整机内存概览信息
MemTotal:                             11731076 kB
AshmemUsed:                             198375 kB
IonTotalUsed:                          1155076 kB
GpuTotalUsed:                          2640712 kB
ReclaimAvailBuffer:                    1722368 kB
realtime:	2026/01/21 10:11:12

*****************************
LOGGER_MEMCHECK_PROC_INFO		<- 内存节点信息
ctx_101      10648      10648 used summary:28672 grow:0 driver:28672 kmd:0 jit:0
ctx_65      20246      20056 used summary:2324946944 grow:11534336 driver:6557696 kmd:557056 jit:0
进程名:
Channel: Texture (Total memory: 2253957888)
26:                   24 / 1187905536
Total used memory: 2370686388
Total allocated memory: 2396626944
Total purged memory: 0
Total using heap: 22
*****************************
LOGGER_MEMCHECK_RENDER_SERVICE_MEM		<- RS进程的内存使用情况
get info realtime:	2026/01/21 10:11:12
-------------------------------[ability]-------------------------------
----------------------------------RenderService----------------------------------
dumpMem: 
----------
RenderService caches:
RSImageCache:
      Size	            Type	    Type,UseCnt,IsUnMap,UnMapCnt	     Pid	                 Wid	     Uid	                             SurfaceName

从LOGGER_MEMCHECK_PROC_INFO内存节点信息中搜索关键字used summary，排查gpu内存使用量最高的进程。

排查进程gpu内存的分布情况，观察内存占用异常的gpu内存类型，以及各大小内存申请分布状况。

示例：Render Service进程的vulkan image和vulkan buffer占用过高。

vulkan主要用于纹理渲染等用途，从vulkan image中看到，2^24~225大小的图片资源，共有10次申请，占用约334MB，占Total memory比例很高；从vulkan buffer中看到，2^25~226大小的buffer资源，共有13次申请，占用约436MB，占Total memory比例很高；需根据场景以及纹理申请大小排查泄漏点。

ctx_4        923        880 used summary:4096 grow:0 driver:4096 kmd:0 jit:0
ctx_3       1893       1482 used summary:3239936 grow:0 driver:1134592 kmd:1064960 jit:0
ctx_1       1893       1482 used summary:1398829056 grow:0 driver:4509696 kmd:1064960 jit:1441792
render_service
Total U(device): 875046670
Total A(device): 1258405888
Total P(device): 35000320
Total U(host): 57258710
Total A(host): 74153984
Total P(host): 8192
C: vulkan default device : 4837602
C: vulkan image : 399937536
C: vulkan buffer : 459800576
C: vulkan fcp : 523720
C: vulkan program : 4080900
C: vulkan crc buffer : 2898432
C: vulkan hebc header : 2967904
C: cq memory(not in total memory) : 3325952
C: host memory : 57258710
C: vulkan external memory(not in total memory) : 202035200
C: vulkan image (Total memory: 399937536)
  13:                    9 / 36864
  16:                   16 / 524288
  17:                   20 / 1310720
  18:                    6 / 884736
  19:                   46 / 17039360
  20:                    4 / 2588672
  21:                    3 / 3670016
  22:                    3 / 11468800
  24:                    2 / 28180480   
  25:                   10 / 334233600   
// 25表示image大小，范围在2^24~2^25；10表示个数；334233600表示内存占用大小，单位Byte。
 C: vulkan buffer (Total memory: 459800576)
  20:                    5 / 2621440
  21:                    4 / 4194304
  22:                    2 / 4194304
  23:                    3 / 12582912
  26:                   13 / 436207616
// 26表示buffer大小，范围在2^25~2^26；13表示个数；436207616表示内存占用大小，单位Byte。

结合业务代码分析泄漏点。
根据使用场景，在开发态使用Allocation模板抓取内存栈信息，分析内存申请释放情况。参考基础内存：Allocation分析。

排查方向：
- 应用自渲染：
  - VK内存申请/释放没有配对vkAllocateMemory/vkFreeMemory。
  - OpenGLES内存申请/释放没有配对。
    - image创建和销毁：eglCreateImageKHR/eglDestroyImageKHR。
    - buffer创建/销毁：glGenBuffers/glDeleteBuffers。
  - OpenCL内存申请/释放没有配对。
    - image创建/销毁：clCreateImage/clReleaseMemObject。
    - buffer创建和销毁：clCreateBuffer/clReleaseMemObject。
- RS统一渲染：
  - 单次渲染了一个分辨率较高的超大图导致gpu内存超标。
  - 短时间内发送了过多的绘制指令导致RS侧累计的进程内存使用量超过阈值触发管控。
  - 应用通过list view无限创建Render node，导致RS的gpu内存部分持续走高，总内存也持续走高。

分析结论

应用存在gpu内存泄漏，导致应用进程被终止。

修改建议

程序需要正确管理分配的资源，使用完毕后需立刻释放。相关分析方法参考gpu泄漏和gpu_rs泄漏。