debuggerd阻塞问题导致冻屏

最新推荐文章于 2024-08-23 14:59:10 发布

我把葡萄酿成酒

最新推荐文章于 2024-08-23 14:59:10 发布

阅读量3k

点赞数

分类专栏：工程实践

本文链接：https://blog.csdn.net/ffmpeg4976/article/details/48666265

版权

本文分析了debuggerd64进程在系统中因连接ndebugsocket阻塞导致的冻屏问题。通过研究进程状态、strace和系统日志，发现可能由NativeCrashListener运行异常或持有锁造成。为解决此问题，提出了两种修改方案：1) NativeCrashListener退出时删除socket文件，防止debuggerd阻塞；2) 在debuggerd连接时设置超时机制，以避免长时间阻塞。

摘要由CSDN通过智能技术生成

1 问题背景：
    产线和测试组低概率出现一些冻屏，当时拿到测试组的手机，经过定位发现手机冻屏的原因是debuggerd64一直处于阻塞状态，发现重启一下debuggerd64进程手机就恢复了。当时定位只看到debuggerd64位进程一直处于unix_stream_connect连接状态，并没有想到更多的线索。

1.1     弯路和想当然：
当时第一眼认为是google如下问题的引入的：当时我们跟google沟通，让他们帮忙解决了system_server在dump mediaserver模式错误的问题，google的改法是从debuggerd64进程里面redirect 32bit debuggerd，中间用了socket。
https://android-review.googlesource.com/#/c/123592/
https://android-review.googlesource.com/#/c/123572/
https://android-review.googlesource.com/#/c/124120/
这块代码进行了重新reveiw和压力测试，并没有发现异常，奇怪？

1.2 问题定位：
后来由于时间的原因，一直没有在定位。产线和测试组仍旧低概率发现由于此原因导致冻屏；
曾经发现当手机在emmc写测试大io状态下，更容易复现。写了一些压力apk去模拟，但是也没有复现出来。
2015/6/24号，测试组又发生了一次冻屏，这次有时间好好思考一下为什么：
首先看了看手机debuggerd64进程的状态，仍旧是阻塞状态，
cat /proc/393/stack
[<0000000000000000>] __switch_to+0x70/0x7c
[<0000000000000000>] unix_wait_for_peer+0x94/0xc0
[<0000000000000000>] unix_stream_connect+0x148/0x424
[<0000000000000000>] SyS_connect+0x78/0xc0
[<0000000000000000>] cpu_switch_to+0x48/0x4c
[<0000000000000000>] 0xffffffffffffffff
unix_stream_connect这个东西永远不返回，如果发生tombstone，watchdog，anr在dump stack的时候都会通过debuggerd64进行stack，如果这个一直阻塞，会阻塞发生问题的进程：
root      392   1     2156   996   00a7156c f76fa9cc S /system/bin/debuggerd
root      393   1     4176   1552 00b3b3c4 855eacd8 S /system/bin/debuggerd64