应用Binder线程耗尽导致systemserver anr并重启问题

最新推荐文章于 2024-08-29 20:08:30 发布
最新推荐文章于 2024-08-29 20:08:30 发布
阅读量1.2w 收藏 29
点赞数
分类专栏： linux Android

SystemServer ANR 最终导致重启的分析

涉及文件：
1 bugreport
2 BinderTrace
3 WDT

AA :
从Bugreport中找到kill system_server的关键字，如下：

W Watchdog: *** WATCHDOG KILLING SYSTEM PROCESS: Blocked in handler on i/o thread (android.io)
06-27 09:41:10.844  1000   894  1788 W Watchdog: i/o thread stack trace:
06-27 09:41:10.844  1000   894  1788 W Watchdog:     at android.os.BinderProxy.transactNative(Native Method)
06-27 09:41:10.844  1000   894  1788 W Watchdog:     at android.os.BinderProxy.transact(Binder.java:789)
06-27 09:41:10.844  1000   894  1788 W Watchdog:     at com.android.internal.telephony.ITelephony$Stub$Proxy.getTetherApnRequired(ITelephony.java:4099)
06-27 09:41:10.844  1000   894  1788 W Watchdog:     at android.telephony.TelephonyManager.getTetherApnRequired(TelephonyManager.java:4968)
06-27 09:41:10.844  1000   894  1788 W Watchdog:     at com.android.server.connectivity.tethering.TetheringConfiguration.checkDunRequired(TetheringConfiguration.java:189)
06-27 09:41:10.844  1000   894  1788 W Watchdog:     at com.android.server.connectivity.tethering.TetheringConfiguration.<init>(TetheringConfiguration.java:100)
06-27 09:41:10.844  1000   894  1788 W Watchdog:     at com.android.server.connectivity.Tethering.updateConfiguration(Tethering.java:263)
06-27 09:41:10.844  1000   894  1788 W Watchdog:     at com.android.server.connectivity.Tethering.-wrap13(Unknown Source:0)
06-27 09:41:10.844  1000   894  1788 W Watchdog:     at com.android.server.connectivity.Tethering$StateReceiver.onReceive(Tethering.java:809)
06-27 09:41:10.844  1000   894  1788 W Watchdog:     at android.app.LoadedApk$ReceiverDispatcher$Args.lambda$-android_app_LoadedApk$ReceiverDispatcher$Args_52497(LoadedApk.java:1320)
06-27 09:41:10.844  1000   894  1788 W Watchdog:     at android.app.-$Lambda$aS31cHIhRx41653CMnd4gZqshIQ.$m$7(Unknown Source:4)
06-27 09:41:10.844  1000   894  1788 W Watchdog:     at android.app.-$Lambda$aS31cHIhRx41653CMnd4gZqshIQ.run(Unknown Source:39)
06-27 09:41:10.844  1000   894  1788 W Watchdog:     at android.os.Handler.handleCallback(Handler.java:790)
06-27 09:41:10.844  1000   894  1788 W Watchdog:     at android.os.Handler.dispatchMessage(Handler.java:99)
06-27 09:41:10.844  1000   894  1788 W Watchdog:     at android.os.Looper.loop(Looper.java:171)
06-27 09:41:10.844  1000   894  1788 W Watchdog:     at android.os.HandlerThread.run(HandlerThread.java:65)
06-27 09:41:10.844  1000   894  1788 W Watchdog:     at com.android.server.ServiceThread.run(ServiceThread.java:46)
06-27 09:41:10.844  1000   894  1788 W Watchdog: *** GOODBYE!

查看进程被杀原因：Binder IO block导致，那么接下来需要追查system_server正在跟谁进行binder通讯

BB :
从BinderTraces文件中查看进程894 相关transaction相关信息，如下：

    Line 3092:   pending transaction 6820434: ffffffe2bb9a6d80 from 894:1080 to 1854:0 code 17 flags 10 pri 0:130 r1 node 12820 size 80:0 data ffffff8026005438
    Line 3094:   pending transaction 6820815: ffffffe202187a80 from 894:1162 to 1854:0 code 61 flags 10 pri 0:120 r1 node 14448 size 92:0 data ffffff8026005758
    Line 3108:   pending transaction 6821061: ffffffe262236980 from 894:3197 to 1854:0 code 14 flags 10 pri 0:120 r1 node 12820 size 80:0 data ffffff8026006318
    Line 3109:   pending transaction 6821064: ffffffe262236700 from 894:1792 to 1854:0 code 6 flags 10 pri 0:120 r1 node 12820 size 100:0 data ffffff80260063c0
    Line 3148:   pending transaction 6824766: ffffffe2623b3e80 from 894:1547 to 1854:0 code 6 flags 10 pri 0:112 r1 node 12820 size 100:0 data ffffff8026009ff8
    Line 3149:   pending transaction 6827279: ffffffe24d98fe00 from 894:1582 to 1854:0 code 14 flags 10 pri 0:120 r1 node 12820 size 80:0 data ffffff802600b7d8
    Line 8842:     outgoing transaction 6820434: ffffffe2bb9a6d80 from 894:1080 to 1854:0 code 17 flags 10 pri 0:130 r1
    Line 8848:     outgoing transaction 6820815: ffffffe202187a80 from 894:1162 to 1854:0 code 61 flags 10 pri 0:120 r1
    Line 8858:     outgoing transaction 6824766: ffffffe2623b3e80 from 894:1547 to 1854:0 code 6 flags 10 pri 0:112 r1
    Line 8866:     outgoing transaction 6827279: ffffffe24d98fe00 from 894:1582 to 1854:0 code 14 flags 10 pri 0:120 r1
    Line 8874:     outgoing transaction 6821064: ffffffe262236700 from 894:1792 to 1854:0 code 6 flags 10 pri 0:120 r1
    Line 8887:     outgoing transaction 6821061: ffffffe262236980 from 894:3197 to 1854:0 code 14 flags 10 pri 0:120 r1
    Line 11051:     incoming transaction 6827914: ffffffe22b82b400 from 894:1497 to 794:1495 code 4 flags 10 pri 1:89 r1 node
    
可以看到894正在跟1854通讯，


Tips:
pending transaction: 记录当前所有进程和线程 TODO队列的transaction.
outgoing transaction: 当前线程transaction_stack, 由该线程发出的事务;
incoming transaction: 当前线程transaction_stack, 由需要线程接收的事务;
pending transactions: 记录当前进程总的pending事务;

CC :
从WDT文件中查看Binder:1854_相关信息，如下:

"Binder:1854_1" prio=5 tid=8 Blocked
  | group="main" sCount=1 dsCount=0 flags=1 obj=0x14801768 self=0x7212c14400
  | sysTid=1875 nice=0 cgrp=default sched=0/0 handle=0x72038d74f0
  | state=S schedstat=( 13768917056 19184339770 80523 ) utm=843 stm=533 core=0 HZ=100
  | stack=0x72037dd000-0x72037df000 stackSize=1005KB
  | held mutexes=
  at com.qualcomm.qti.internal.telephony.QtiIccPhoneBookInterfaceManager.getAdnRecordsInEf(QtiIccPhoneBookInterfaceManager.java:90)
  - waiting to lock <0x02e2601a> (a java.lang.Object) held by thread 40
  at com.android.internal.telephony.UiccPhoneBookController.getAdnRecordsInEfForSubscriber(UiccPhoneBookController.java:123)
  at com.android.internal.telephony.IccProvider.loadFromEf(IccProvider.java:430)
  at com.android.internal.telephony.IccProvider.query(IccProvider.java:104)
  at android.content.ContentProvider.query(ContentProvider.java:1105)
  at android.content.ContentProvider.query(ContentProvider.java:1197)
  at android.content.ContentProvider$Transport.query(ContentProvider.java:247)
  at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:102)
  at android.os.Binder.execTransact(Binder.java:708)
  
  
  。。。。。。
  。。。。。。



"Binder:1854_7" prio=5 tid=40 Waiting
  | group="main" sCount=1 dsCount=0 flags=1 obj=0x14804270 self=0x7212ceb400
  | sysTid=2970 nice=0 cgrp=default sched=0/0 handle=0x72004524f0
  | state=S schedstat=( 13309285438 19466662160 79302 ) utm=740 stm=590 core=4 HZ=100
  | stack=0x7200358000-0x720035a000 stackSize=1005KB
  | held mutexes=
  at java.lang.Object.wait(Native method)
  - waiting on <0x0c573241> (a java.lang.Object)
  at com.qualcomm.qti.internal.telephony.uicccontact.QtiSimPhoneBookAdnRecordCache.queryAdnRecord(QtiSimPhoneBookAdnRecordCache.java:149)
  at com.qualcomm.qti.internal.telephony.uicccontact.QtiSimPhoneBookAdnRecordCache.requestLoadAllAdnLike(QtiSimPhoneBookAdnRecordCache.java:177)
  - locked <0x0c573241> (a java.lang.Object)
  at com.qualcomm.qti.internal.telephony.QtiIccPhoneBookInterfaceManager.getAdnRecordsInEf(QtiIccPhoneBookInterfaceManager.java:98)
  - locked <0x02e2601a> (a java.lang.Object)
  at com.android.internal.telephony.UiccPhoneBookController.getAdnRecordsInEfForSubscriber(UiccPhoneBookController.java:123)
  at com.android.internal.telephony.IccProvider.loadFromEf(IccProvider.java:430)
  at com.android.internal.telephony.IccProvider.query(IccProvider.java:104)
  at android.content.ContentProvider.query(ContentProvider.java:1105)
  at android.content.ContentProvider.query(ContentProvider.java:1197)
  at android.content.ContentProvider$Transport.query(ContentProvider.java:247)
  at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:102)
  at android.os.Binder.execTransact(Binder.java:708)
  
  。。。。。。
  。。。。。。
  
  "Binder:1854_F" prio=5 tid=63 Blocked
  | group="main" sCount=1 dsCount=0 flags=1 obj=0x13f80e10 self=0x720206aa00
  | sysTid=7468 nice=0 cgrp=default sched=0/0 handle=0x71fd9eb4f0
  | state=S schedstat=( 14860937747 20246234650 84331 ) utm=866 stm=620 core=3 HZ=100
  | stack=0x71fd8f1000-0x71fd8f3000 stackSize=1005KB
  | held mutexes=
  at com.qualcomm.qti.internal.telephony.QtiIccPhoneBookInterfaceManager.getAdnRecordsInEf(QtiIccPhoneBookInterfaceManager.java:90)
  - waiting to lock <0x02e2601a> (a java.lang.Object) held by thread 40
  at com.android.internal.telephony.UiccPhoneBookController.getAdnRecordsInEfForSubscriber(UiccPhoneBookController.java:123)
  at com.android.internal.telephony.IccProvider.loadFromEf(IccProvider.java:430)
  at com.android.internal.telephony.IccProvider.query(IccProvider.java:104)
  at android.content.ContentProvider.query(ContentProvider.java:1105)
  at android.content.ContentProvider.query(ContentProvider.java:1197)
  at android.content.ContentProvider$Transport.query(ContentProvider.java:247)
  at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:102)
  at android.os.Binder.execTransact(Binder.java:708)

可以看到1854的16个binder全部耗尽了，并且都held by thread 40，
可以看到tid=40正在Waitting，通过callStack可以看到卡在QtiSimPhoneBookAdnRecordCache.java:149中
然后根据详情做相关修改即可


 

荒漠苍鹰
关注
专栏目录
Binder线程数耗尽引起系统异常分析
shusuanly的博客
02-07 1609
Binder线程数耗尽引起system_server进程异常，进而导致系统瘫痪
Android中的线程（一）
川峰的博客
06-08 2385
文章目录new ThreadAsyncTaskHandlerThreadIntentServiceJobIntentService new Thread 缺乏统一管理，无限制创建，可能占用过多系统资源导致死机或oom，不推荐。 AsyncTask 场景：需要知晓任务执行的进度,多个任务串行执行 缺点：生命周期和宿主的生命周期不同步,有可能发生内存泄漏,默认情况所有任务串行执行 class MyAsyncTask extends AsyncTask<String, String, String>.
systemserver binder线程耗尽问题分析及优化方案
一杯咖啡的专栏
08-04 3201
systemserver binder线程耗尽问题分析及优化方案 一、问题场景描述 Systemserver作为系统核心进程，它提供了大量的binder服务，响应大量客户端binder请求，同时也会作为客户端，访问其它进程，如果systemserver有大量请求同时发出或者systemserver同时响应大量请求，并且处理请求的进程又遇到某些原因block住，这样长时间block，就会导致SWT发生。下面描述几个典型场景。 场景1： 场景描述： 整个流程就是进程A，例如com.med...
Android BinderProxy leak 原理分析
xuyongqz的博客
07-31 1532
在结合压测的log，我们发现在压测的时候，有app会非常频繁的show toast。从目前的分析来看，还是因为压力测试，由于频繁使用binder调用，导致BinderProxy数据急剧增加，而GC又有滞后性，当Free RAM足够大的时候，GC的频率会降低，最终导致BinderProxy数量操过了系统的限制。说明问题点不在这里，通过上面的set方法，我们能够看到，当BinderProxy 的size操过20000之后，会有dump信息打印，接下来我们看看能不能通过dump信息看出什么端倪。
system server ANR 一种分析方法 -- Android JVM异常重启简析
热门推荐
changliangdoscript的专栏
05-10 1万+
SYSTEM SERVER进程ANR 一般会导致java vm不停重启，还好保留了自动打印log到文件中的方法，出现这种概率性问题，从log入手就简单多了。   1. 找到SYSTEM server的PID，一般在logcat中会有这么一句      System server process 2094 has been created； 2094就是你需要的PID 2. 根据pid去搜索
Binder开辟线程数过多导致主线程ANR异常
似霰的博客
06-18 229
Binder开辟线程数过多导致主线程ANR异常
Android SystemServer ANR总结
dzy_mails的专栏
08-23 264
SystemServer ANR
2805076 /system/WTD/android.fg_blocked_67fc4997-ims导致binder耗尽
从0到1，突破自己
04-02 717
binder耗尽，几乎所有的binder都是处理定位相关； "android.fg" prio=5 tid=10 Native | group="main" sCount=1 dsCount=0 flags=1 obj=0x156c0630 self=0x7fb2ec9800 | sysTid=28050 nice=0 cgrp=default sched=0/0 handle=0x7ec1702d50 | state=S schedstat=( 75607657358 36450530...
Android中高级进阶开发面试题冲刺合集（四）
m0_64420071的博客
10-10 783
以下主要针对往期收录的面试题进行一个分类归纳整理，方便大家统一回顾和参考。本篇是第四集~
面试官：“遇到过死锁问题吗？怎么发生的？如何解决呢？“
m0_73088370的博客
08-24 475
说到死锁，大家可能都不陌生，每次遇到死锁，总会让计算机产生比较严重的后果，比如资源耗尽，界面无响应等。集合中的每一个进程（或线程）都在等待只能由本集合中的其他进程（或线程）才能引发的事件，那么该组进程是死锁的。对于这个定义大家可能有点迷惑，换一种通俗的说法就是：死锁是指两个或两个以上的线程，在执行过程中，由于竞争资源或者由于彼此通信，而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。
如何快速定位Android问题
jieike88的博客
06-30 1099
本章通过案例讲解如何快速定位Android运行出现的问题。
Android跨进程调用，Binder线程池溢出导致ANR
weixin_46039528的博客
06-25 522
sysTid=1863是进程号，ANR发生在at android.os.BinderProxy.transactNative(Native method)，在transcatNative函数中，transcatNative 函数式客户端发起端的函数，猜测这是Binder卡住，客户端等待响应中，这种问题基本上就是我们在跨进程通信调用服务端的时候太频繁了，大部分原因是由于业务逻辑，才会写这种代码，解决办法就是降低调用的频率，或者延迟调用，设置一些时间间隔，app端不要频繁调用服务端。
【项目问题实战】system_server主线程阻塞导致大量SCREEN_OFF anr产生，无法待机
最新发布
疯子与天才就在一念之间
08-29 224
搜索slow dispatch可以看到，system_server主线程Handler全部在处理hdmi的msg，一条接一条，可以推断出，从mainlog来看，广播入队，分发，定时器设置，直到Receiver超时。所有的打印都正常，因此排除客制化方案导致的广播机制问题。问题初分析：str待机需要等所有SCREEN_OFF广播处理完毕后才会待下去，发生异常时SCREEN_OFF处理慢，且很多超时。设备连接外设，TV str待机慢，需要等待几分钟才待下去。打开一些log开关复测。
利用systrace中跟踪binder通信过程
kill150的专栏
06-16 979
从trace中可以看到，1546 InputReader线程通过binder向surfaceflinger(501)的线程发送了消息，请求requestNextVsync.systrace抓取到的trace日志中会记录android系统的很多通信过程，其中也包括了binder的通信细节。红框：现场名字及线程号，这里是截图所以没有体现出来，这个线程是system_server中的1102 1546 InputReader线程。点击绿色横条，可以看到这个thread是运行在CPU5上。
Binder异常，导致的手机重启
深厚的积淀才有人生的升华
05-08 2046
手机出现重启，拿到LOG之后，先解开看一 下栈 信息systemServer发生NE错误，进一步看，    #00 pc 000000000006d7b4  /system/lib64/libc.so (tgkill+8)    #01 pc 000000000006abd4  /system/lib64/libc.so (pthread_kill+64)    #02 pc 0000000000...
android swt问题分析,Android System ANR caused SWT restart issue
weixin_29014939的博客
05-27 251
一、问题现象1、用户直观看到的现象是System先ANR。2、ANR之后系统重启。测试方法：在录音的界面不停的滑动音量进度条，同时座机给测试机打电话，电话没有接通，只见界面冻结，弹出ANR，接着系统重启。Platform：MT6732Android版本：4.4.4KKBuildType：user系统软件版本：SWA3A+UMA0系统RAM:1GB问题概率：≈2%参考机行为：1、低概率问题，暂无参考...
Android源码阅读---system_server进程
helloWen
03-21 1131
system_server进程 文章目录system_server进程1. 初始化参数2. forkSystemServer 创建一个进程3. handleSystemServerProcess4. systemServer的main方法4.1 startBootstrapServices4.2 startCoreServices4.3 startOtherServices system_serv...
Android System Server
大山
04-28 301
System Server Android 系统服务进程 system_server，运行着各种服务，比如 PMS, AMS, WMS 等等。 该进程是启动时，由 Zygote 启动。 frameworks/base/core/java/com/android/internal/os/ZygoteInit.java private static Runnable forkSystemSer...
ANR产生的原因及其定位分析
weixin_42331253的博客
12-08 284
ANR是Android 中独有的概念，全称Application No Responding 1、ANR产生的原因 只有当应用程序的UI线程响应超时才会引起ANR 超时产生的原因有两种， 1) dispatchTimeout输入事件分发超时，一般由于主线程在五秒内没有响应输入事件 2) BroadcastReceiver没有在系统设定的时间内完成并返回 2、产生原因分类 由主线程导致的情况...
android anr binder
06-09
ANR (Application Not Responding) 是 Android 系统中的一种错误，当应用程序在主线程上进行耗时操作而无法响应用户输入时，系统会弹出 ANR 对话框，提示用户等待或强制关闭应用程序。Binder 是 Android 系统中的一种进程间通信机制，它负责在不同的进程之间传递数据和消息。 在 Android 应用程序中，如果应用程序在主线程上进行了耗时操作而无法响应用户输入，系统会认为应用程序已经崩溃并弹出 ANR 对话框。如果应用程序涉及到跨进程通信，例如使用 Binder 机制与其他进程进行通信，那么如果 Binder 通信超时或者出现死锁，也可能会导致 ANR 错误的发生。因此，在 Android 应用程序中，需要注意避免在主线程上进行耗时操作，以及合理使用进程间通信机制，避免出现 ANR 错误。
评论 3
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值