NE问题分析

大家好，又见面了，我是你们的朋友全栈君。

一. 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往往时间点和代码位置都没有相关性,如果能猜测到可能的代码逻辑可以加log复测,如果比较随机,就需要使用HWASan(内存踩踏检测工具)进行复测
开启HWSan方法:
对于整个系统开启: 构建版本时添加属性: SANTIIZE_TARGET=“hwadress”
单独对sf进程开HWSan: 根据具体crash的点开对应so的HWSan,比如:
libgui.so: http://gerrit.scm.adc.com:8080/#/c/9367352/
libsurfaceflinger.so: http://gerrit.scm.adc.com:8080/#/c/9367154/4/libc/Android.bp
HWSan分析方法:
HWSan复现问题后在android log中会明确指出问题发生的直接原因,搜索关键字: AddressSanitizer:
如何确定HWSan是否打开成功:
通过DPS命令, adb shell dumpsys Surfaceflinger –dps –debug-asan 去触发一个数组越界,log中有asan相关log就是触发成功
或者直接adb pull打开HWASan的lib,搜关键字hwsan,lize._hwsan_in即为开启成功
4).主动触发coredump
产生的coredump文件在/data/core下
5).MTK db
MTK平台在发生NE,SWT,ANR时会产生db.db就是包含各种debug需要的log,堆栈,coredump,CPU,GPU,内存,文件系统信息的压缩包
MTK发生NE后生成的db文件在目录/data_aee下以.NE结尾
db分为fatal和非fatal,sf,system server等系统关键进程的NE都是fatal的,所以只需要关注fatal的就行了,可以打开db_history搜索进程关键字来找到对应的db文件
db文件一般提供给MTK分析,我们也可以使用MTK QAAT工具自己去解dbg文件 https://eservice.mediatek.com/eservice-portal/issue_manager/update/96659541 ALPS05600986这个case直接申请下载就行了

二.sf hang问题

hang就是卡死,sf这边实现了看门狗nwachcall,当sf卡死主线程和binder线程卡死超过3s后,会抓取log,堆栈信息保存到本地,并且会通过EAP回传
1.获取卡死时的堆栈信息
  完整logkit工具抓的log包,nwatchcall log放在log.tar.gz压缩包里面,或者是log文件夹下/data/persist_log/DCS/de/psw_multimedia_perf,这里面最重要的一个文件就是nbacktrace,保存了sf卡死时堆栈的信息
  有一点,有时候问题是底软的同事转过来的,他们通过监控系统SWT重启,发现是因为sf造成的卡死,题中的log只有他们的SWT回传,没有nwatchcall回传,所以需要联系测试去eap系统下载才行
2.分析问题
  sf卡死一般分为以下几种
  1).sf自身逻辑造成的卡死,一般是死锁
  2).驱动或者gpu造成的卡死,一般伴随fence timeout,或者hwcomposer驱动异常log,看堆栈是否挂在gpu库里
  3).系统运行缓慢,io,cpu,loading过重导致sf运行缓慢,这种情况sf连续两个时间点的堆栈不一样,这时候要看log上有没有lmk或者lowmem字样,分析是否是系统问题
  4).sf被binder阻塞,比如虚拟屏(sf作为bufferqueue的生产者,要queue buffer)卡死,或者sf notifylistener时app不响应binder卡死等,这类问题要看binder对端的状态,可能是对端被冻结,或者binder耗尽
  总之就是找到证据转给对应的模块

三.定屏黑屏问题

1.连接adb执行   ps -A|grep surfaceflinger
确定sf的pid是否较大(一般sf比较小,1000以内),确定sf是否crash过.sf作为系统关键进程,crash后android会重启,重启后新分配的sf pid会比较大,几千,
2.得到sf pid后执行   debuggerd -b {sf pid}
得到sf的堆栈,可以多执行几次,抓到不同时间点的堆栈,到这一步,基本可以确定黑屏或者定屏是不是sf本身能够造成的卡死了
3.执行截图命令 如果能成功截到图,基本判断是驱动问题  screencap -p /sdcard/1.png
4.如果上面确定是sf卡死造成的,则 adb pull /data/persist_log/DCS/de/psw_multimedia_perf 把nwatchcall抓到的现场堆栈和log导出来继续分析