system_server 重启问题,请binder大神出马

沧海一粟之 2016-06-21 04:03:02
system_server 重启,因为binder线程长时间没有处理完binder请求并且达到最大binder个数,导致watchdog把他reset了。如下是log,所有binder线程栈都是如下这样,完全一样。我的疑问是:

第一,pc指针是kernel的“binder_thread_read+0x417/0xd7b”,这里0x471是基于函数的偏移,后面/0xd7b是什么东西?
第二,所有线程都是这样,说明所有线程都阻塞在这,说明这是一个阻塞操作,并且,并且,这是一个非函数的阻塞,因为如果是函数,最后pc就不是在binder_thread_read函数里面了。
第三,这也不是死锁,因为这里binder锁也是个函数,如果是阻塞在锁,最后pc应该停留在锁函数里面
第三,基于第二点,问题是我在binder_thread_read函数内并没有发现有这样的阻塞啊?

"Binder:2928_6" prio=5 tid=77 Native
| group="main" sCount=1 dsCount=0 obj=0x137ff670 self=0xd8c61f00
| sysTid=3574 nice=0 cgrp=default sched=0/0 handle=0xd637f910
| state=S schedstat=( 39575585087 28168991843 202072 ) utm=2632 stm=1325 core=2 HZ=100
| stack=0xd6283000-0xd6285000 stackSize=1014KB
| held mutexes=
kernel: binder_thread_read+0x417/0xd7b
kernel: binder_ioctl+0x6ec/0x8b0
kernel: compat_sys_ioctl+0xc0/0x13e0
kernel: ia32_sysret+0x0/0x5
native: #00 pc ffffe43e [vdso] (__kernel_vsyscall+14)
native: #01 pc 00086f1c /system/lib/libc.so (__ioctl+28)
native: #02 pc 00031a97 /system/lib/libc.so (ioctl+71)
native: #03 pc 000478a7 /system/lib/libbinder.so (_ZN7android14IPCThreadState14talkWithDriverEb+343)
native: #04 pc 000488f2 /system/lib/libbinder.so (_ZN7android14IPCThreadState15waitForResponseEPNS_6ParcelEPi+370)
native: #05 pc 000485b7 /system/lib/libbinder.so (_ZN7android14IPCThreadState8transactEijRKNS_6ParcelEPS1_j+199)
native: #06 pc 0003a835 /system/lib/libbinder.so (_ZN7android8BpBinder8transactEjRKNS_6ParcelEPS1_j+85)
native: #07 pc 000e8540 /system/lib/libandroid_runtime.so (???)
native: #08 pc 0105bbd1 /data/dalvik-cache/x86/system@framework@boot.oat (Java_android_os_BinderProxy_transactNative__ILandroid_os_Parcel_2Landroid_os_Parcel_2I+221)
at android.os.BinderProxy.transactNative(Native method)
at android.os.BinderProxy.transact(Binder.java:615)
at android.app.ApplicationThreadProxy.dumpMemInfo(ApplicationThreadNative.java:1360)
at com.android.server.am.ActivityManagerService.dumpApplicationMemoryUsage(ActivityManagerService.java:15994)
at com.android.server.am.ActivityManagerService$MemBinder.dump(ActivityManagerService.java:2486)
at android.os.Binder.doDump(Binder.java:409)
at android.os.Binder.dump(Binder.java:396)
at android.os.Binder.onTransact(Binder.java:347)
at android.os.Binder.execTransact(Binder.java:565)
...全文
671 1 打赏 收藏 转发到动态 举报
写回复
用AI写文章
1 条回复
切换为时间正序
请发表友善的回复…
发表回复
NorZ 2016-09-26
  • 打赏
  • 举报
回复
遇到同样的问题,楼主是如何分析出“binder线程长时间没有处理完binder请求并且达到最大binder个数,导致watchdog把他reset”的结论的呢?另外,binder的最大个数是多少,如何得知呢?
千里马8年Android系统及应用开发经验,曾担任过美国unokiwi公司移动端技术总监兼架构师,对系统开发,性能优化,应用高级开发有深入的研究,Android开源定制ROM Lineage的贡献者之一,国内首家线下开辟培训Android Framework课程,拥有2年的Android系统培训经验。成为腾讯课堂专业负责android framework课程分享第一人,致力于提高国内android Framework水平Android Framework领域内是国内各大手机终端科技公司需要的人才,应用开发者都对Android系统充满着好奇,其中的binder是重中之重,都说无binder无Android,binde是Android系统的任督二脉。课程水平循序渐进,由中级再到高级,满足各个层次水平的android开发者。1、灵活使用binder跨进程通信,在app端对它的任何api方法等使用自如2、可以单独分析android系统源码中任何binder部分,分析再也没有难度3、掌握binder驱动本质原理,及对应binder驱动怎么进行跨进程通信,及内存等拷贝方式数据等4、对binder从上层的java app端一直到最底层的内核binder驱动,都可以顺利理通5、针对系统开发过程中遇到的binder报错等分析方法,及binder bug案例学习6、针对面试官任何的binder问题都可以对答自如7、socket这种跨进程通信实战使用8、针对android源码中使用的socket源码轻松掌握9、android系统源码中最常见的socketpair中双向跨进程通信10、使用socket实现一个可以让app执行shell命令的程序

80,337

社区成员

发帖
与我相关
我的任务
社区描述
移动平台 Android
androidandroid-studioandroidx 技术论坛(原bbs)
社区管理员
  • Android
  • yechaoa
  • 失落夏天
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧