NE问题分析

最新推荐文章于 2024-03-25 16:03:45 发布

Zakariyya.

最新推荐文章于 2024-03-25 16:03:45 发布

阅读量3.3k

点赞数

分类专栏：笔记

本文链接：https://blog.youkuaiyun.com/m0_45265996/article/details/121424749

版权

本文详细介绍了Android系统中出现的Native Error (NE)问题的分析步骤和常见类型，包括堆栈信息查找、解析、常见问题分析以及解决办法。讨论了空指针、多线程竞争、内存踩踏等问题，并提出使用HWASan工具进行内存踩踏检测。此外，还提及了主动触发coredump以及MTK平台特有的db.db文件用于故障排查。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一. crash(NE)问题

1.找到堆栈信息
一般堆栈在Android log或者tombstore里面,android log里面直接搜libsurfaceflinger或者surfaceflinger定位到log,SW-WD
tombstore文件是系统在系统发生NE是抓到的堆栈信息,可能会包含多份文件,找的需要的即可
2.解析堆栈
backtrace信息, 主要看调用栈,我们能从中得到发生问题的具体代码行号,比如:

#01 pc 00000000000642fc  /apex/com.android.runtime/lib64/bionic/libc.so (je_free+116) (BuildId: 554cb674fad07588ff08040bb89924c9)

#01                                               //帧栈编号
00000000000642fc                                  //so内偏移地址
/apex/com.android.runtime/lib64/bionic/libc.so    //具体执行在哪个so
je_free                                           //具体执行在哪个函数
+116                                              //函数内偏移地址

具体方法是使用工具addr2line得到对应文件和行号
addr2line -Cie 具体so so内偏移地址

3.分析
1).常见的空指针解应用类问题采取规避方法进行判空处理,举例:818848 488093 330523
2).根据代码推断出是多线程的访问竞争引起的问题,比如图层在子线程析构类的,由于图层或者buffer释放后使用或者重复释放造成的问题,通常进行加锁处理举例:1112033
3).内存踩踏问题,通常不容易处理,因为发生踩踏和真正导致sf crash往往时间点和代码位置都没有相关性,如果能猜

最低0.47元/天解锁文章