本文分析了手机kernel启动时因空指针导致的system_server watchdog问题。问题源于surfaceflinger主线程等待中断处理函数，但该函数因空指针未执行完毕，进而阻塞了system_server。通过分析system_server和surfaceflinger的trace，发现kernel中synaptics_rmi4_add_and_update_tp_data方法和kthread_data方法出现了空指针错误。深入研究发现，中断处理函数引发的空指针异常使进程陷入D状态，修复这个问题的关键在于解决最初的kernel空指针异常。
一. 问题描述
1.1 现象
手机kernel启动时狂点屏幕会导致手机卡死重启．
1.3 结论
因为surfaceflinger主线程在等中断处理函数执行执行结束，而中断处理函数一直没有执行完，所以导致surfaceflinger的主线程卡住．这时候system_server通过binder跨进程去调用 surfaceflinger中的方法时，由于surfaceflinger卡住了，所以system_server也会被卡住，最终导致了system_server watchdog．
1.4修复链接：
二. 初步分析
2.1 查看system_server trace
一般对于watchdog问题，我们都会先看看system_server的那一个线程出了问题，出现问题的具体调用栈如下：
从这里我们能看到system_server的binder线程在向surfaceflinger发起跨进程调用时被block了，具体的调用方法是createSurface，那么接下来我们就去看看surfaceflinger的trace，看看它在干什么事情．
2.1 查看surfaceflinger trace
我下了好几份log，都没有发现watchdog文件中有surfaceflinger的trace，没有能继续往下分析，只能先去找没有打印出surfaceflinger trace的原因.
2.2 surfaceflinger打不出trace的怀疑点
①debuggerd出问题了？
不会出问题，要是它出了问题，其他native进程也不会打印出对应的trace．
②watchdog类里把中surfaceflinger这个要抓trace的进程给去掉了？然后查看了下c8对应的代码：
surfaceflinger这个进程还在默认的列表里面，这就比较奇怪了，然后再继续下载了几十份Log，然而没有一份log有surfaceflinger的trace.
继续看下相应的Log，debuggerd确实打印了相应的log
12-29 20:42:17.814 695 831 W SurfaceFlinger: setTransactionState timed out waiting for previous animation frame |
③surfaceflinger进程中的莫个线程Ｄ状态了．
由于没有现场，无法确认．
由于第一，第二种都被排除了，只有第三种最可疑了，如果是第三种情况的话，那就肯定是bsp同事合入的代码有问题导致的．
2.3 排查当时合入的代码
由于没有surfaceflinger的trace，暂时无法继续往下分析了．只能去排查当时进了哪些代码，并且让测试帮忙跑稳定性测试，看看能不能复现．然后排查了一波代码，发现几个改动比较大的，发了邮件让相关的owner自己检查一下，具体的change如下：
最低0.47元/天 解锁文章
扫一扫
3809
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
