抖音 renderD128 系统级疑难OOM分析与解决背景抖音长期存在renderD128内存占用过多导致的虚拟内存O

背景

抖音长期存在renderD128内存占用过多导致的虚拟内存OOM，且多次出现renderD128内存激增导致OOM指标严重劣化甚至发版熔断。因受限于闭源的GPU驱动、现场有效信息极少、线上线下的Native内存检测工具均未能检测到相关内存分配等原因，多个团队都进行过分析，但一直未能定位到问题根因，问题反馈到厂商也一直没有结论。

以往发生renderD128内存激增时，解决办法往往都是通过二分法去定位导致问题MR进行回滚(MR代码写法并无问题，仅仅是正常调用系统Api)，但是回滚业务代码会影响业务正常需求的合入，也无法从根本上解决该问题，而且每次都会消耗我们大量人力去分析排查，因此我们有必要投入更多时间和精力定位根因并彻底解决该问题。在历经数月的深入分析和排查后，我们最终定位了问题根因并彻底解决了该问题，也取得了显著的OOM收益，renderD128导致发版熔断的问题再也没有发生过。

接下来，将详细介绍下我们是如何一步步深入分析定位到问题根因，以及最终如何将这个问题给彻底解决的。

问题分析

问题特征

主要集中在华为Android10系统，表现为renderD128内存占用过多。

机型特征： 联发科芯片、PowerVR GPU

如：华为y6p/华为畅享e

OS version: Android 10(主要），少量Android 8.1.0/9.0/11.0/12.0

abi： armeabi-v7a, armeabi

崩溃原因： 虚拟内存耗尽，主要由于/dev/dri/renderD128类型的内存占用过多（1G左右）

问题复现

我们根据抖音过往导致renderD128内存激增的MR，找到了一种能稳定复现该问题的办法“新增View，并调用View.setAlpha会引发renderD128内存上涨”。

复现机型：华为畅享10e(Android 10)

测试方式：

对照组：新增10个view，每个view设置背景色，不设置透明度，查看绘制前后内存变化
实验组：新增10个view，每个view设置背景色，并设置alpha为0.5，查看绘制10个view前后renderD128类内存变化

测试结果：

对照组: 新增View，renderD128内存无变化
实验组: 新增View，renderD128内存出现显著上涨，且每增加1个View，renderD128内存增加大概25M

结论： 如果view被设置了透明度，绘制时会申请大量内存，且绘制完成不会释放

监控工具完善

我们在线上线下都开启了虚拟内存监控，但是均并未找到renderD128相关的内存监控信息（分配线程、堆栈等）

关键接口代理

以下是我们Hook相关接口开启虚拟内存监控的情况

接口	是否可以监控	备注
mmap/mmap64/mremap/__mmap2	监控不到
ioctl	仅监控到一个命令，但该命令并没有映射内存操作	1. 命令调用前后renderD128相关内存并无变化

这个命令相关的ioctl调用频繁 | | 上层接口 | 播放视频时没有监控到这些函数的调用（比较奇怪，讲道理应该是有调用的） | | | open | 并未监控到设备文件打开的时机和路径 | |

根据hook ioctl接口获取到的相关堆栈（虽然ioctl操作并没有影响内存，也可通过堆栈找到关键so库）

libsrv_um.so

gralloc.mt6765.so

调查内存映射方式

从内核源码中寻找线索

由于关键接口代理均无法监控到renderD128相关的内存申请，此时猜想：可能是在内核中分配的内存？

于是找到了华为畅享e的内核源代码，阅读其中DRM驱动的相关代码

找到了唯一一个ioctl调用对应命令（0xc0206440）的定义和参数数据结构。

根据参数的数据结构，很容易理解驱动应该是根据传入的bridge_id和bridge_func_id来决定做何操作的。（根据堆栈其实也能大致推测每个id对应的操作，但此处暂时不对其进行研究）

但除此之外，在内核代码中并没有找到“内存是在内核中分配的”证据，猜测应该还是用户空间申请的，比较有“嫌疑”的库是libdrm.so、libsrv_um.so和gralloc.mt6765.so

从驱动和关键so库中寻找线索

libdrm库

DRM

DRM是Linux内核层的显示驱动框架，它把显示功能封装成 open/close/ioctl 等标准接口，用户空间的程序调用这些接口，驱动设备，显示数据。libdrm库封装了DRM driver提供的这些接口。通过libdrm库，程序可以间接调用DRM Driver

但libdrm库中的drm_mmap是调用 mmap或__mmap2（都是监控中的接口）

#if defined(ANDROID) && !defined(__LP64__)
extern void *__mmap2(void *, size_t, int, int, int, size_t);

static inline void *drm_mmap(void *addr, size_t length, int prot, int flags,
                             int fd, loff_t offset)
{
   /* offset must be aligned to 4096 (not necessarily the page size) */
   if (offset & 4095) {
      errno = EINVAL;
      return MAP_FAILED;
   }

   return __mmap2(addr, length, prot, flags, fd, (size_t) (offset >> 12));
}
#else
/* assume large file support exists */
#  define drm_mmap(addr, length, prot, flags, fd, offset) \
              mmap(addr, length, prot, flags, fd, offset)

mesa3D

mesa3D

mesa3D中是通过调用libdrm库中的接口，间接调用DRM Driver的

gitlab.freedesktop.org/mesa/mesa

在mesa的源代码中找到了类似libsrv_um.so中PRVSRVBridgeCall的函数 pvr_srv_bridge_call

static int pvr_srv_bridge_call(int fd,
                               uint8_t bridge_id,
                               uint32_t function_id,
                               void *input,
                               uint32_t input_buffer_size,
                               void *output,
                               uint32_t output_buffer_size)
{
   struct drm_srvkm_cmd cmd = {
      .bridge_id = bridge_id,
      .bridge_func_id = function_id,
      .in_data_ptr = (uint64_t)(uintptr_t)input,
      .out_data_ptr = (uint64_t)(uintptr_t)output,
      .in_data_size = input_buffer_size,
      .out_data_size = output_buffer_size,
   };

   int ret = drmIoctl(fd, DRM_IOCTL_SRVKM_CMD, &cmd);
   if (unlikely(ret))
      return ret;

   VG(VALGRIND_MAKE_MEM_DEFINED(output, output_buffer_size));

   return 0U;
}

同时发现了BridgeCall的相关id定义

通过提交的commit了解到这部分代码是为powerVR rogue GPU增加的驱动

commit链接:gitlab.freedesktop.org/mesa/mesa/-…

存在renderD128内存问题的机型使用的GPU也是PowerVR GPU，那么内存申请关键逻辑应该确实就在libsrv_um.so和gralloc.mt6765.so中

Huawei Y6p - Full phone specifications

libsrv_um.so与gralloc.mt6765.so

暂时无法在飞书文档外展示此内容

奇怪的是，libsrv_um.so中只有munmap的符号，却没有mmap的符号（gralloc.mt6765.so同样没有）

这比较不符合常理，一般来说，mmap和munmap都是成对出现的，猜测有三种可能性：

在其他库中mmap
用其他方式实现mmap操作
1. 使用dlsym拿到mmap等的符号，再调用 ❌
  1. 这种情况，使用inline hook是可以监控到的
2. 调用ioctl实现mmap操作 ❌
  1. 并未监控到
3. 直接使用系统调用 ✅
  1. 在libsrv_um.so中发现调用了syscall，系统调用号是0xC0(192)，正是mmap的系统调用号！
  2. gralloc.mt6765.so同libsrv_um.so，也是通过系统调用进行mmap的！

结论:hook syscall 应该可以监控到renderD128相关内存的调用！

验证监控方案

监控方式：

使用bytehook劫持了libsrv_um.so和gralloc.mt6765.so中对syscall的调用
记录renderD128内存的变化

测试： 播放视频

测试结果：

系统调用mmap可以监控到renderD128内存的分配
在播放视频期间renderD128内存增长大小符合通过系统调用mmap分配的大小

堆栈：

内存变化：

结论: 底层驱动可能考虑到架构适配或者效率问题，直接使用系统调用而非通用接口调用。在之前的监控中并未考虑到这种情况，所以会导致监控不全。

相关内存分配

内存监控工具完善之后，从线上我们收集到如下的堆栈信息：

从堆栈上可以看到 libIMGegl.so有一个方法KEGLGetPoolBuffers，这个方法中会调用PVRSRVAcquireCPUMapping申请内存；

从“KEGLGetPoolBuffers”这个方法名可以推断：

有一个缓存池
可以调用KEGLGetPoolBuffers从缓存池中获取buffer
如果缓存池中有空闲buffer，会直接分配，无须从系统分配内存
如果缓存池中无空闲buffer，会调用PVRSRVAcquireCPUMapping从系统中申请内存

我们继续通过hook KEGLGetPoolBuffers 打印一些关键日志来确认猜想

日志中前两次调用KEGLGetPoolBuffers没有申请内存，符合“存在空闲buffer直接分配”的猜想。

后面的多次调用，每次都会连续调用5次 PVRSRVAcquireCPUMapping，分配5个大小不一的内存块（猜测应该是5类buffer），一共25M内存，和前面测试的结果刚好一致

相关内存释放

既然有内部分配，必然有其对应的内存释放，我们hook 泄漏线程RenderThread线程的munmap调用，抓到下面的堆栈，libsrv_um.so中相对偏移0xf060处(对应下面栈回溯#04栈帧，0xf061最后一位是1代表是thumb指令)的方法是DevmemReleaseCpuVirtAddr，但DevmemReleaseCpuVirtAddr这个方法并没有导出，glUnmapBuffer其实是调用了PVRSRVReleaseCPUMapping方法，在PVRSRVReleaseCPUMapping调用了DevmemReleaseCpuVirtAddr，进而最终调用到munmap方法释放内存的。

之所以在堆栈中没有PVRSRVReleaseCPUMapping这层栈帧，是因为PVRSRVReleaseCPUMapping跳转到DevmemReleaseCpuVirtAddr使用的是指令b（而非bl指令）

（glUnmapBuffer --> PVRSRVReleaseCPUMapping --> DevmemReleaseCpuVirtAddr --> ... --> munmap ）

#01 pc 00009f41  /data/app/com.example.crash.test-bqPIslSQVErr7gyFpcHl_w==/lib/arm/libnpth_vm_monitor.so （proxy_munmap)
#02 pc 0001474b  /vendor/lib/libsrv_um.so
#03 pc 000115d9  /vendor/lib/libsrv_um.so
#04 pc 0000f061  /vendor/lib/libsrv_um.so（DevmemReleaseCpuVirtAddr+44）
#05 pc 00015db1  /vendor/lib/egl/libGLESv2_mtk.so (glUnmapBuffer+536)
#06 pc 003b865d  /system/lib/libhwui.so!libhwui.so (offset 0x244000) (GrGLBuffer::onUnmap()+54)
#07 pc 001a0eb3  /system/lib/libhwui.so (GrResourceProvider::createPatternedIndexBuffer(unsigned short const*, int, int, int, GrUniqueKey const*)+174)
#08 pc 001666b9  /system/lib/libhwui.so (GrResourceProvider::createQuadIndexBuffer()+24)
#09 pc 00153df1  /system/lib/libhwui.so (GrResourceProvider::refQuadIndexBuffer()+44)
#10 pc 001535c9  /system/lib/libhwui.so (GrAtlasTextOp::onPrepareDraws(GrMeshDrawOp::Target*)+328)

PVRSRVAcquireCPUMapping和PVRSRVReleaseCPUMapping是libsrv_um.so中进行内存分配和释放的一对方法

同理，KEGLGetPoolBuffers和KEGLReleasePoolBuffers是libIMGegl.so中分配和释放缓存buffer的一对方法

但在测试过程中，并没有看到在为buffer分配内存之后有调用PVRSRVReleaseCPUMapping释放内存，在绘制结束前，会调用KEGLReleasePoolBuffers释放buffer（但并未释放内存），查看KEGLReleasePoolBuffers的汇编发现方法内部只是对buffer标记可用，并不存在内存释放。

（左图KEGLGetPoolBuffers申请buffer，会申请内存；右图KEGLReleasePoolBuffers释放buffer，但不释放内存）

看来这个缓存池可能是统一释放内存的，由于libIMGegl.so中大部分方法都没有符号，从这层比较难推进，不妨再从上层场景分析一下，跟绘制相关的缓存池会什么时候释放呢？首先想到的可能是Activity销毁的时候，经过测试发现并没有……

但是在一次测试中发现在Activity销毁之后，过了一段时间（1min左右）再启动一个新的Activity时突然释放了一堆renderD128相关的内存，抓到的是下面的堆栈。RenderThreaad中会执行销毁CanvasContext的任务，每次销毁CanvasContext时都会释放在一定时间范围内（30s）未使用的一些资源。销毁CanvasContext的时机是Activity Destroy时。（这里其实有些疑问，应该还有释放时机没有被发现）

    #01 pc 0000edc1  /data/app/com.example.crash.test-o-BAwGot5UWCmlHJALMy2g==/lib/arm/libnpth_vm_monitor.so
    #02 pc 0001d29b  /vendor/lib/libIMGegl.so
    #03 pc 0001af31  /vendor/lib/libIMGegl.so
    #04 pc 000187c1  /vendor/lib/libIMGegl.so
    #05 pc 0001948b  /vendor/lib/libIMGegl.so
    #06 pc 00018753  /vendor/lib/libIMGegl.so
    #07 pc 0000b179  /vendor/lib/libIMGegl.so
    #08 pc 0000f473  /vendor/lib/libIMGegl.so (IMGeglDestroySurface+462)
    #09 pc 000171bd  /system/lib/libEGL.so (android::eglDestroySurfaceImpl(void*, void*)+48)
    #10 pc 0025d40b  /system/lib/libhwui.so!libhwui.so (offset 0x245000) (android::uirenderer::renderthread::EglManager::destroySurface(void*)+30)
    #11 pc 0025d2f7  /system/lib/libhwui.so!libhwui.so (offset 0x245000) (android::uirenderer::skiapipeline::SkiaOpenGLPipeline::setSurface(ANativeWindow*, android::uirenderer::renderthread::SwapBehavior, android::uirenderer::renderthrea 
    #12 pc 00244c03  /system/lib/libhwui.so!libhwui.so (offset 0x243000) (android::uirenderer::renderthread::CanvasContext::setSurface(android::sp<android::Surface>&&)+110)
    #13 pc 00244af5  /system/lib/libhwui.so!libhwui.so (offset 0x243000) (android::uirenderer::renderthread::CanvasContext::destroy()+48)
    #15 pc 0023015f  /system/lib/libhwui.so!libhwui.so (offset 0x208000) (std::__1::packaged_task<void ()>::operator()()+50)
    #16 pc 0020da97  /system/lib/libhwui.so!libhwui.so (offset 0x208000) (android::uirenderer::WorkQueue::process()+158)
    #17 pc 0020d8f5  /system/lib/libhwui.so!libhwui.so (offset 0x208000) (android::uirenderer::renderthread::RenderThread::threadLoop()+72)
    #18 pc 0000d91b  /system/lib/libutils.so (android::Thread::_threadLoop(void*)+182)
    #19 pc 0009b543  /apex/com.android.runtime/lib/bionic/libc.so!libc.so (offset 0x8d000) (__pthread_start(void*)+20)

总结

renderD128类内存导致的OOM问题，并非由于内存泄漏，而是大量内存长期不释放导致。在大型APP中，Activity存活的时间可能会很长，如果缓存池只能等到Activity销毁时才能释放，大量内存长期无法释放，就极易发生OOM。

优化方案

手动释放内存

方案一：释放空闲buffer

从相关内存的分配和释放章节的分析来看，get & release buffer的操作有点不对称，我们期望：

分配缓存：有可用buffer直接使用；无可用buffer则申请新的；
释放缓存：标记buffer空闲，空闲buffer达到某一阈值后则释放。

而现状是空闲buffer达到某一阈值后并不会释放，是否可以尝试手动释放呢？

首先需要了解缓存池的结构

由于相关so代码闭源，我们通过反汇编推导出缓存池的结构，大致如下图所示，pb_global是缓存池的管理结构体，其中的buffers_list中分别保存了5类buffer的list，内存组织方式如下示意

KEGLReleasePoolBuffers中会标记每一个buffer->flag为0（空闲）

暂时无法在飞书文档外展示此内容

手动释放内存的方式

在KEGLReleasePoolBuffers标记buffer为空闲之后，检查当前空闲buffer个数是否超过阈值（或者检查当前render D128相关内存是否超过阈值），如果超过阈值则释放一批buffer，并将buffer从链表中取下。

（相关代码如下👇）

static void release_freed_buffer(pb_ctx_t* ctx) {
    /** 一些检查和判空操作会省略 **/
    ...
    /** 阈值检查 **/
    if (!limit_check(ctx)) return;

    // 拿到buffer_list
    pb_buffer_list_t* buffers_list = ctx->pb_global->buffers_list;

    pb_buffer_info_t *buffer_info, *prev_info;
    for (int i = 0; i < 5; i++) {
        buffer_info = buffer_info->buffers[i];
        if (buffer_info == NULL) continue;

        /** 第一个buffer不释放，简化逻辑 **/
        while(buffer_info) {
            prev_info = buffer_info;
            buffer_info = buffer_info->next;

            if (buffer_info && buffer_info->flag == 0) {
                int ret = pvrsrvReleaseCPUMapping((void**)buffer_info->sparse_buffer->cpu_mapping_info->info);

                LOGE("%s, release cpu mapping ret: %d", __FUNCTION__, ret);
                if (ret == 0) {
                    buffer_info->flag = 1;
                    buffer_info->sparse_buffer->mmap_ptr = NULL;
                    prev_info->next = buffer_info->next;
                    buffers_list->buffer_size[i]--;
                    free(buffer_info);
                    buffer_info = prev_info;
                }
            }
        }
    }
}

方案效果

测试环境和方式与前面“问题复现”章节一致

内存释放时机	绘制结束后renderD128相关内存大小	结果比较
每次释放缓存	33M 左右	与不设置透明度的对照组结果接近
renderD128内存> 100M	86M 左右	100M以下，符合预期
renderD128内存> 300M	295M 左右	跟实验组一致，因为并没有超过300M的阈值。符合预期
buffer总数 > 5	33M 左右	与不设置透明度的对照组结果接近，绘制结束时会释放完所有空闲buffer
buffer总数 > 10
buffer总数 > 20	295M 左右	跟实验组一致，因为并没有超过20个buffer的阈值（10个view大概会用到10～15个buffer）。符合预期
空闲buffer > 5	138M 左右	空闲buffer个数不太可控，无法精确控制内存水位
空闲buffer > 10	33M 左右

方案结论:

这个方案虽然也可缓解问题，但是存在以下问题：

性能影响（理论，未测）
1. 增加了内存申请和释放的概率，会有一定的性能影响
2. 每次进行阈值判定，都需要统计当前buffer/内存的值，频繁调用接口时，也会影响性能
稳定性
1. 硬编码缓存池相关的数据结构，如果有些机型数据结构不一致的话，就可能会崩溃

这个方案应该不是最优解，先做备用方案，再探索一下

方案二：上层及时释放资源

从前面“相关内存释放”章节的分析可知，缓存池的内存并不是不会释放，而是释放时机很晚，那么能否早点释放呢？

查看CanvasContext的释放路径，仅发现了一个可操作点（尝试了一些方式都会崩溃，会释放掉正在使用的资源），CacheManager::trimStaleResources方法中可以把释放30s内未使用的资源，改成释放1s（或10s）内未使用的资源

修改指令：MOVW R2, #30000 ==> MOVW R2,#1000

（相关代码如下👇）

#define ORIGIN_TIME_LIMIT_INST      0x5230f247 // 30s
#define NEW_TIME_LIMIT_INST      0x32e8f240 // 1s 提前构造好的指令编码
#define FUNC_SYM "_ZN7android10uirenderer12renderthread12CacheManager18trimStaleResourcesEv"

static void change_destroy_wait_time() {
    /** 一些检查和判空操作会省略 **/
#ifdef __arm__
    void* handle = dlopen("libhwui.so");
    // 从trimStaleResources方法的起始地址开始搜索内存
    void* sym_ptr = dlsym(handle, FUNC_SYM);

    sym_ptr = (void*)((uint32_t)sym_ptr & 0xfffffffc);

    uint32_t* inst_start = (uint32_t*)sym_ptr;
    uint32_t* search_limit = inst_start + 12;

    while(inst_start < search_limit) {
        /* 找到并修改对应指令 */
        if (*inst_start == ORIGIN_TIME_LIMIT_INST) {
            if(mprotect((void*)((uint32_t)inst_start & (unsigned int) PAGE_MASK), PAGE_SIZE, PROT_READ | PROT_WRITE | PROT_EXEC)) {
                return;
            }

            *inst_start = NEW_TIME_LIMIT_INST;
            flash_page_cache(inst_start);

            if(mprotect((void*)((uint32_t)inst_start & (unsigned int) PAGE_MASK), PAGE_SIZE, PROT_READ|PROT_WRITE|PROT_EXEC)) {
                return;
            }
            break;
        }

        inst_start++;
    }
#endif
}

方案结论： 该方案还是依赖于Activity销毁，只是销毁后能更快释放资源，所以缓解内存方面起到的作用很有限

控制缓存池增长

在尝试前面两个方案之后，这个问题逐渐让人崩溃，似乎已经没有什么好的解决办法了，已经准备就此放弃。

新的突破点

山重水复疑无路，柳岸花明又一村。在后续的一次压测中，我们发现了一个新的突破点“每次调用一次renderD128 内存会上涨25M，但是并不是无限上涨，上涨到1.3G左右就不再增长了”，且另外翻看线上相关OOM问题，renderD128内存占用最多的也在1.3G上下，由此我们大胆猜测renderD128 内存缓存池大小应该是有上限的，这个上限大概在1.3G上下，那么我们可以尝试从调小缓存池的阈值入手。

再次尝试:

我们再次尝试复现该问题，并hook相关内存分配；从日志可以看到，在内存增长到1.3G后

下一次调用KEGLGetPoolBuffers获取buffer时，返回值是0（代表分配失败）
再下一次调用KEGLGetPoolBuffers，返回值是1（代表分配成功），但没有申请内存

再增加多一点信息，发现当KEGLGetPoolBuffers获取buffer失败后，会有KEGLReleasePoolBuffers调用，释放了大量buffer，之后再重新调用KEGLGetPoolBuffers

KEGLGetPoolBuffers end, a1: 0xd1b95068, a2: 0x1, ret: 0x1 ==> before: 1265852416, after: 1292066816, alloc: 26214400
KEGLGetPoolBuffers end, a1: 0xd1b95068, a2: 0x1, ret: 0x1 ==> before: 1292066816, after: 1318281216, alloc: 26214400
KEGLGetPoolBuffers end, a1: 0xd1b95068, a2: 0x1, ret: 0x0 ==> before: 1318281216, after: 1318281216, alloc: 0
KEGLReleasePoolBuffers end, ret: 1 ==> before: 1318281216, after: 1318281216, release: 0
KEGLReleasePoolBuffers end, ret: 1 ==> before: 1318281216, after: 1318281216, release: 0
KEGLReleasePoolBuffers end, ret: 1 ==> before: 1318281216, after: 1318281216, release: 0
...
KEGLReleasePoolBuffers end, ret: 1 ==> before: 1318281216, after: 1318281216, release: 0
KEGLReleasePoolBuffers end, ret: 1 ==> before: 1318281216, after: 1318281216, release: 0
KEGLReleasePoolBuffers end, ret: 1 ==> before: 1318281216, after: 1318281216, release: 0
KEGLGetPoolBuffers end, a1: 0xd1b95068, a2: 0x1, ret: 0x1 ==> before: 1318281216, after: 1318281216, alloc: 0
KEGLGetPoolBuffers end, a1: 0xd1b95068, a2: 0x1, ret: 0x1 ==> before: 1318281216, after: 1318281216, alloc: 0
KEGLGetPoolBuffers end, a1: 0xd1b95068, a2: 0x1, ret: 0x1 ==> before: 1318281216, after: 1318281216, alloc: 0

从堆栈看应该是提前flush了，所以就可以释放之前的buffer

#01 pc 0000ebf5  /data/app/com.example.crash.test-1hHKnp6FBSv-HjrVtXQo1Q==/lib/arm/libnpth_vm_monitor.so （proxy_KEGLReleasePoolBuffers)
#02 pc 00047c2d  /vendor/lib/egl/libGLESv2_mtk.so
#03 pc 00046a7b  /vendor/lib/egl/libGLESv2_mtk.so (ResetSurface)
#04 pc 00028bf7  /vendor/lib/egl/libGLESv2_mtk.so
#05 pc 000d2165  /vendor/lib/egl/libGLESv2_mtk.so (RM_FlushHWQueue)
#06 pc 00028c73  /vendor/lib/egl/libGLESv2_mtk.so 
#07 pc 000453fd  /vendor/lib/egl/libGLESv2_mtk.so (PrepareToDraw)
#08 pc 0001d977  /vendor/lib/egl/libGLESv2_mtk.so (glDrawArrays+738)
#09 pc 00009edd  /system/lib/libGameGraphicsOpt.so (hw_glDrawArraysHookV2+18)
#10 pc 001d1769  /system/lib/libhwui.so (GrGLGpu::sendMeshToGpu(GrPrimitiveType, GrBuffer const*, int, int)+74)
#11 pc 001d15f3  /system/lib/libhwui.so (GrMesh::sendToGpu(GrMesh::SendToGpuImpl*) const+38)
#12 pc 001d13e5  /system/lib/libhwui.so (GrGLGpu::draw(GrRenderTarget*, GrSurfaceOrigin, GrPrimitiveProcessor const&, GrPipeline const

2. #### 方案三：KEGLGetPoolBuffers中限制buffer分配

根据上面的分析，发现可以尝试：

Hook KEGLGetPoolBuffers函数，判断内存增长到一定阈值后，在KEGLGetPoolBuffers函数中就直接返回0，触发其内部的空闲buffer释放
空闲buffer释放之后，才允许分配buffer（如下流程）

暂时无法在飞书文档外展示此内容

方案结论: 该方案需要每次分配内存前读取maps获取renderD128占用内存大小，对性能不是很友好

方案四：修改缓存池阈值

从上面的分析，我们知道KEGLGetPoolBuffers函数返回0时分配失败，会开始释放buffer。我们继续反汇编KEGLGetPoolBuffers函数，根据KEGLGetPoolBuffers的返回值为0 可以回溯到汇编中进行阈值判断的逻辑

v8：buffers_list

v7：buffer类型（0～4）

v8+4*v7+24：v7这个buffer类型的buffer数量(右图中的buffer_size[i]

v49：buffer_info

v49 + 28: buffer_limit 缓存池中每种类型的buffer 的阈值(右图中的buffer_limits)

简单来说，这里将buffer_limits与buffer_size[i]进行比较，如果buffer_size[i]大于等于阈值，就会返回0，分配失败

接下来的操作就很简单了，只需对buffer_limits进行修改就行，在测试设备上buffer_limits值是50（50*25M 大约是1.25G），我们将buffer_limits改小一点就可以将renderD128内存值控制在一个更小的阈值范围内，以此降低renderD128内存占用。

（相关代码如下👇）

int opt_mtk_buffer(int api_level, int new_buffer_size) {
    ...(无关代码省略）
    if (check_buffer_size(new_buffer_size)) {
        prefered_buffer_size = new_buffer_size;
    }

    KEGLGetPoolBuffers_stub = bytehook_hook_single(
            "libGLESv2_mtk.so",
            NULL,
            "KEGLGetPoolBuffers",
            (void*)proxy_KEGLGetPoolBuffers,
            (bytehook_hooked_t)bytehook_hooked_mtk,
            NULL);
    ...(无关代码省略）

    return 0;
}

static void* proxy_KEGLGetPoolBuffers(void** a1, void* a2, int a3, int a4) {
    //修改buffer_limits
    modify_buffer_size((pb_ctx_t*)a1);
    void* ret = BYTEHOOK_CALL_PREV(proxy_KEGLGetPoolBuffers, KEGLGetPoolBuffers_t, a1, a2, a3, a4);
    BYTEHOOK_POP_STACK();
    return ret;
}

static void modify_buffer_size(pb_ctx_t* ctx) {
    if (__predict_false(ctx == NULL || ctx->node == NULL || ctx->node->buffer_inner == NULL)) {
        return;
    }

    if (ctx->node->buffer_inner->num == ORIGIN_BUFFER_SIZE) {
        ctx->node->buffer_inner->num = prefered_buffer_size;
    }
}

Demo验证：

缓存值阈值	内存峰值
50	1.3G
20	530M
10	269M

方案结论: 该方案修改少，性能影响小，且稳定性可控

最终方案

通过的上面的分析，由于方案四“修改缓存池阈值”修改少，性能影响小，且稳定性可控 ，最终我们决定选用该方案。

修复效果

开启修复实验后相关机型OOM崩溃率显著下降近50% ，观察数周之后各项业务指标也均为正向，符合预期。全量上线后大盘renderD128相关OOM也大幅下降，另外renderD128导致发版熔断的情况从此再也没有发生过。

总结

在分析内存问题时，不论是系统申请的内存还是业务申请的内存，都需要明确申请逻辑和释放逻辑，才能确定是否发生泄漏还是长期不释放，再从内存申请和释放逻辑中寻找可优化点。

相关资料

华为畅享e内核源代码链接:consumer.huawei.com/en/opensour…
mesa源代码链接:gitlab.freedesktop.org/mesa/mesa

抖音 renderD128 系统级疑难OOM分析与解决

背景

问题分析

问题特征

问题复现

监控工具完善

关键接口代理

调查内存映射方式

从内核源码中寻找线索

从驱动和关键so库中寻找线索

验证监控方案

相关内存分配

相关内存释放

总结

优化方案

手动释放内存

方案一：释放空闲buffer

方案二：上层及时释放资源

控制缓存池增长

新的突破点

方案四：修改缓存池阈值

最终方案

修复效果

总结