NE问题分析

#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内偏移地址

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导出来继续分析