1、关键字

appfreeze，ion内存泄漏

2、问题描述

设备OH版本：3.2release

故障场景：12台设备在进行24小时稳定性压测的过程中，有4台设备单台上报几百次appfreeze故障，其他设备也分别上报几十次appfreeze问题，故障分布在不同应用，故障堆栈也不固定。

3、问题原因

3.1正常机制

设备在进行稳定性压测的过程中，不会集中上报大量不同应用、堆栈、故障原因的appfreeze问题

3.2异常场景

系统存在问题，导致整机性能下降，导致集中上报大量不同应用、堆栈、故障原因的appfreeze问题。

4 解决方案

解决内存泄漏问题

回退修改相机crash的代码，将申请的bufffer数量由8修改回3.

uint32_t StreamBase::GetBufferCount()
{
    //return 8; // 3: buffer count
    return 3; // 3: buffer count
}

 

5 定位过程

1、使用脚本将每台机器的appfreeze故障根据应用、堆栈进行分类定界，发现单台机器中故障应用基本覆盖系统所有应用，故障堆栈和故障类型比较随机，很多故障日志里的堆栈信息不全。

2、查询流水日志中应用查杀记录，发现系统剩余内存还有150M左右，不符合常规内存极低的情况

3、查询故障日志中cpu的占用情况，基本都没有超过90%

4、查看kmsg日志，发现大量打印 ion_new_alloc dumb buffer fail,说明ion 申请不到buffer, 没有可用buffer内存了。

5、查看hidumper内存情况，发现Lost RAM 非常高，存在异常,结合上面的分析，可以确定系统存在内存泄漏

6、通过hdc命令查看sys/kernel/debug/dma_buf/bufinfo 的内容，发现确实存在ion内存泄漏。

7、本系统使用ion内存的仅有相机相关的服务，手动命令kill -9 camera_host 后，bufinfo 中ion内存占用减少，确定是相机的底层服务camera_host存在ion内存泄漏导致系统可用buffer耗尽，导致上层应用大量上报appfreeze问题。

8、排查该版本合入的链接中涉及到ion内存申请相关修改的情况，其中有笔camera_service申请buffer由3个改为8个的修改，实际camera_host只使用了3个buffer,怀疑该处buffer存在泄漏的可能，经过回退并压测，确认是该处的问题。

6 知识分享

appfreeze问题分析方法和步骤

appfreeze问题定位原则：

1、应用优先定位，确认根因为其他模块，需和相应模块对齐，由其接力分析。

2、若系统存在严重内存泄漏导致系统运行缓慢，大量应用上报各种appfreeze问题的情况，需优先解决系统问题。

appfreeze问题分析步骤：

（1）、查看故障日志中Reason和msg信息，确认故障类型；不同故障类型检测原理和分析方法不一样，根据故障类型和故障描述确定大致分析方向

（2）、查看故障日志，确定故障应用进程号，故障时间，并找到故障时间附近的hilog日志，方便后续分析。

（3）、查看故障日志中故障应用主进程堆栈，大致推测当前故障应用在进行什么操作

（4）、查看故障日志中的Binder调用链，确定是否有Binder对端等待导致本应用阻塞的情况

（5）、查看故障日志中的CPU调用信息，确定故障时间附近CPU占用是否非常高，有没有系统繁忙的情况

（6）、查看故障日志中故障应用的内存占用信息，判断故障应用内存占用是否正常

（7）、通过上述步骤大概确定问题是系统原因，还是应用原因，还是其他服务的原因，确定责任田后，由其接力分析。