作者：王小二C? 2019/09/04

前言

今天遇到一個問題，應用工程師分析是系統層的問題，然后就把這個鍋給了我。最后我又把鍋甩回給了應用工程師。

異常log如下:

I [2019-08-18 10:11:08 GMT+8] binder: 1433:1561 transaction failed 29201/-28, size 828-8 line 3135 W BroadcastQueue: Can't deliver broadcast to com.xxxx.xxxxx (pid 4712). Crashing it. W BroadcastQueue: Failure sending broadcast Intent { act=android.intent.action.BATTERY_CHANGED flg=0x60000010 (has extras) } W BroadcastQueue: android.os.DeadObjectException: Transaction failed on small parcel; remote process probably died W BroadcastQueue: at android.os.BinderProxy.transactNative(Native Method) W BroadcastQueue: at android.os.BinderProxy.transact(Binder.java:1127) W BroadcastQueue: at android.app.IApplicationThread$Stub$Proxy.scheduleRegisteredReceiver(IApplicationThread.java:1237) W BroadcastQueue: at com.android.server.am.BroadcastQueue.performReceiveLocked(BroadcastQueue.java:496) W BroadcastQueue: at com.android.server.am.BroadcastQueue.deliverToRegisteredReceiverLocked(BroadcastQueue.java:715) W BroadcastQueue: at com.android.server.am.BroadcastQueue.processNextBroadcastLocked(BroadcastQueue.java:875) W BroadcastQueue: at com.android.server.am.BroadcastQueue.processNextBroadcast(BroadcastQueue.java:834) W BroadcastQueue: at com.android.server.am.BroadcastQueue$BroadcastHandler.handleMessage(BroadcastQueue.java:172) W BroadcastQueue: at android.os.Handler.dispatchMessage(Handler.java:106) W BroadcastQueue: at android.os.Looper.loop(Looper.java:193) W BroadcastQueue: at android.os.HandlerThread.run(HandlerThread.java:65) W BroadcastQueue: at com.android.server.ServiceThread.run(ServiceThread.java:44)

初步分析

從log來看的確好像是binder驅動第3135行出現問題（line 3135）

binder: 1433:1561 transaction failed 29201/-28, size 828-8 line 3135

一看Binder.c的代碼發現對不上3135行，估計是編譯版本不一樣，因為測試是user版本，代碼優化了，這怎么辦？我需要在userdebug的版本上復現此問題。

Binder.c 3129 if (target_node && target_node->txn_security_ctx) { 3130 u32 secid; 3131 size_t added_size; 3132 3133 security_task_getsecid(proc->tsk, &secid); 3134 ret = security_secid_to_secctx(secid, &secctx, &secctx_sz); 3135 if (ret) { 3136 return_error = BR_FAILED_REPLY; 3137 return_error_param = ret; 3138 return_error_line = __LINE__; 3139 goto err_get_secctx_failed; 3140 }

聰明機智的我瞬間判斷應該是對應到3164行，應該是binder server無法申請足夠的buffer，別問我怎么想到的，有時候解決問題就得靠猜。

3154 t->buffer = binder_alloc_new_buf(&target_proc->alloc, tr->data_size, 3155 tr->offsets_size, extra_buffers_size, 3156 !reply && (t->flags & TF_ONE_WAY)); 3157 if (IS_ERR(t->buffer)) { 3158 /* 3159 * -ESRCH indicates VMA cleared. The target is dying. 3160 */ 3161 return_error_param = PTR_ERR(t->buffer); 3162 return_error = return_error_param == -ESRCH ? 3163 BR_DEAD_REPLY : BR_FAILED_REPLY; 3164 return_error_line = __LINE__; 3165 t->buffer = NULL; 3166 goto err_binder_alloc_buf_failed; 3167 }

為了證明我判斷是對的，我寫了如下的一個demo安裝到userdebug來制造binder server無法申請足夠的buffer的情況

public class MainActivity extends Activity implements View.OnClickListener { private MyLinear mRoot; private IMyAidlInterface myAidlInterface; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); mRoot = (MyLinear) findViewById(R.id.root); mRoot.setOnClickListener(this); Intent intent = new Intent(this, MyService.class); bindService(intent, new ServiceConnection() { @Override public void onServiceConnected(ComponentName name, IBinder service) { myAidlInterface = IMyAidlInterface.Stub.asInterface(service); } @Override public void onServiceDisconnected(ComponentName name) { } }, Context.BIND_AUTO_CREATE); } @Override public void onClick(View v) { try { while (true) { myAidlInterface.send("dfdafsdfafdasdfadfadsfafd"); } } catch (Exception e) { } } } public class MyService extends Service { @Override public IBinder onBind(Intent intent) { return new MyBinder(); } public class MyBinder extends IMyAidlInterface.Stub { @Override public void send(String e) throws RemoteException { //后面發現這個4秒的卡頓，不加也可以復現此問題 try { Thread.sleep(4000); } catch (Exception ee) { } } } } // IMyAidlInterface.aidl package com.tct.activitydemo; // Declare any non-default types here with import statements interface IMyAidlInterface { /** * Demonstrates some basic types that you can use as parameters * and return values in AIDL. */ oneway void send(String e); }

出現的異常log，和之前log相比，除了行數不對，error code是一樣的都是29201/-28，而且行數果然是3164行，所以我的推測是對的。

//binder: 1433:1561 transaction failed 29201/-28, size 828-8 line 3135 binder: 30286:30286 transaction failed 29201/-28, size 140-0 line 3164

#初步分析結論 廣播的發送失敗是原因，在一次binder通信中，無法向廣播注冊的App的binder驅動中映射的共享內存申請足夠buffer。

#重大發現 我發現出問題的應用注冊了300多個廣播，都是監聽android.intent.action.BATTERY_CHANGED，具體log就不貼了，在bugreport中會有當前系統所有廣播的dumpsys的信息。我貼出meminfo的信息，發現三百多個activity沒有被GC，因為那個廣播是在activity中被動態注冊的，所以變相可以證明注冊了300多個廣播

** MEMINFO in pid 4712 [com.xxxxxxxxxxx] ** .....省略沒用的信息，看下面activity的數量是325 Objects Views: 13600 ViewRootImpl: 2 AppContexts: 329 Activities: 325 Assets: 3 AssetManagers: 0 Local Binders: 352 Proxy Binders: 366 Parcel memory: 887 Parcel count: 2235 Death Recipients: 2 OpenSSL Sockets: 0 WebViews: 0

推測

當這個廣播發送的時候，由于他的接受者有300多個，每一次接收都會在申請一次buffer，如果短時間一下子申請，非常有可能超過binder驅動的(1mb-8kb)/2的限制，有人會問為什么是(1mb-8kb)/2而不是1mb-8kb，因為scheduleRegisteredReceiver是oneway的，對這個有疑問的，可以看一下我的另外一個文章：[[007]一次Binder通信最大可以傳輸多大的數據？]

進一步分析

其實一般分析到這里，對于我來說已經可以把鍋甩回給了應用層，但是這個問題的好奇心促使我繼續分析下去，一定要找到廣播重復注冊的原因。

涉及保密，我把應用層代碼的精簡成自己的代碼

public class MyActivity extends Activity { private MyReceiver receiver; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main2); IntentFilter intentFilter = new IntentFilter(); intentFilter.addAction("fdafdafsdafaffasdfad"); receiver = new MyReceiver(this); getApplication().registerReceiver(receiver, intentFilter); } @Override protected void onDestroy() { try { //因為上下文不同，會導致unregisterReceiver失敗，從而導致MyActivity和MyReceiver，無法被GC unregisterReceiver(receiver); } catch (Exception e) { } super.onDestroy(); } public static class MyReceiver extends BroadcastReceiver { private Context mContext; public MyReceiver(Context context) { mContext = context; } @Override public void onReceive(Context context, Intent intent) { } } }

水落石出

原來應用開發工程師，在registerReceiver和unregisterReceiver使用了不同的context，導致了unregisterReceiver的失敗，從而導致MyReceiver的無法被釋放，而且這個代碼還會導致MyActivity的內存泄露。

舉個例子來還原一下這個現場

小明寄了一份投訴信到信訪局門口的信箱，然后信訪局的1號工作人員拿了這份投訴信，進行處理。這個就是一次完整的oneway的binder通信。但是有一天小明一下子拿了300封投訴信，一封封的塞到信箱里，然后信訪局的1~16號工作人員同時拿了16封信進行處理，但是還是架不住小明的塞信的速度，很快信箱就爆了，小明說了一句：垃圾信訪局，我信還沒有塞完呢。

其實大家可能有點難以理解一次binder通信，內核發生了什么，請看下面圖，看懂下圖，才能知道我在說什么：

References

[1] [007]一次Binder通信最大可以傳輸多大的數據？?簡書地址：https://www.jianshu.com/p/ea4fc6aefaa8

總結

以上是生活随笔為你收集整理的一个看似是系统问题的应用问题的解决过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。