問題描述

JNI全局引用異常導致的重啟問題JNI ERROR (app bug): global reference table overflow (max=51200)'

Log

pid: 1279, tid: 2518, name: Binder:1279_9??>>> system_server <<<

signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------

Abort message: 'art/runtime/indirect_reference_table.cc:132] JNI ERROR (app bug): global reference table overflow (max=51200)'

????x0???0000000000000000??x1???00000000000009d6??x2???0000000000000006??x3???0000000000000008

????x4???0000000000000166??x5???0000800000000000??x6???0000007f0a5ab000??x7???000000000000000c

????x8???0000000000000083??x9???ffffffffffffffdf??x10??0000000000000000??x11??0000000000000001

????x12??0000000000000010??x13??0000000000000030??x14??ffffffffffffffff??x15??ffffffffffffffff

????x16??0000007f069f9ed0??x17??0000007f069a278c??x18??0000000000000000??x19??0000007eddecf4f8

????x20??0000000000000006??x21??0000007eddecf450??x22??000000000000000d??x23??0000007f05ffe000

????x24??0000007f05f4b52b??x25??0000007f05f85440??x26??0000007eddece4f1??x27??0000007f05ffcda0

????x28??0000000000002ff0??x29??0000007eddece3d0??x30??0000007f0699fbb8

????sp???0000007eddece3b0??pc???0000007f069a2794??pstate 0000000060000000

?

backtrace:

????#00 pc 000000000006d794??/system/lib64/libc.so (tgkill+8)

????#01 pc 000000000006abb4??/system/lib64/libc.so (pthread_kill+64)

????#02 pc 0000000000024098??/system/lib64/libc.so (raise+24)

????#03 pc 000000000001c93c??/system/lib64/libc.so (abort+52)

????#04 pc 000000000043581c??/system/lib64/libart.so (_ZN3art7Runtime5AbortEPKc+464)

????#05 pc 00000000000e5e7c??/system/lib64/libart.so (_ZN3art10LogMessageD2Ev+1592)

????#06 pc 000000000024dd48??/system/lib64/libart.so (_ZN3art22IndirectReferenceTable3AddEjPNS_6mirror6ObjectE+308)

????#07 pc 00000000002f2468??/system/lib64/libart.so (_ZN3art9JavaVMExt12AddGlobalRefEPNS_6ThreadEPNS_6mirror6ObjectE+60)

????#08 pc 000000000032de8c??/system/lib64/libart.so (_ZN3art3JNI12NewGlobalRefEP7_JNIEnvP8_jobject+596)

????#09 pc 0000000000101454??/system/lib64/libandroid_runtime.so (_ZN7android20javaObjectForIBinderEP7_JNIEnvRKNS_2spINS_7IBinderEEE+428)

????#10 pc 00000000000f5a3c??/system/lib64/libandroid_runtime.so

????#11 pc 000000007564f254??/data/dalvik-cache/arm64/system@framework@boot-framework.oat (offset 0x19fc000)

log初步分析

根據log，查找到是在frameworks/base/core/jni/android_util_Binder.cpp的javaObjectForIBinder方法中調用NewGlobalRef時出現的問題

?

547 jobject javaObjectForIBinder(JNIEnv* env, const sp<IBinder>& val)

?548 {

?549?????if (val == NULL) return NULL;

?

585?????????jobject refObject = env->NewGlobalRef(

?586?????????????????env->GetObjectField(object, gBinderProxyOffsets.mSelf));

?587?????????val->attachObject(&gBinderProxyOffsets, refObject,

?588?????????????????jnienv_to_javavm(env), proxy_cleanup);

?

這里NewGlobalRef操作后，沒有看到明顯的DeleteGlobalRef操作。會不會是沒有進行DeleteGlobalRef操作導致的溢出呢？

?

解決嘗試

在frameworks/base/core/jni/android_util_Binder.cpp進行添加env->DeleteGlobalRef(refObject);

進行回收操作

547 jobject javaObjectForIBinder(JNIEnv* env, const sp<IBinder>& val)

?548 {????static int scount = 0;//add，記錄調用次數

?549?????if (val == NULL) return NULL;

?

585?????????jobject?refObject?= env->NewGlobalRef(

?586?????????????????env->GetObjectField(object, gBinderProxyOffsets.mSelf));

?587?????????val->attachObject(&gBinderProxyOffsets, refObject,

?588?????????????????jnienv_to_javavm(env), proxy_cleanup);

?

?

595

?596 scount++;

?597 if (scount % 100 == 0)

?598 {

?599?????????ALOGD("=====android_util_Binder.cpp, scount=%d\n", scount);

?600 }

?601

?602???????env->DeleteGlobalRef(refObject);

?603?????????// Note that a new object reference has been created.

?604?????????android_atomic_inc(&gNumProxyRefs);

?605?????????incRefsCreated(env);

?606?????}

?607

?608?????return object;

?609 }

?

編譯運行后，手機卻不能開機了。

分析

547 jobject javaObjectForIBinder(JNIEnv* env, const sp<IBinder>& val)

?548 {

?549?????if (val == NULL) return NULL;

?

585?????????jobject?refObject?= env->NewGlobalRef(

?586?????????????????env->GetObjectField(object, gBinderProxyOffsets.mSelf));

?587?????????val->attachObject(&gBinderProxyOffsets,?refObject,

?588?????????????????jnienv_to_javavm(env),?proxy_cleanup);

在調用中，val為BpBinder，在585行進行了NewGlobalRef操作后，接著在587行調用了attachObject方法，查看該方法

BpBinder.cpp

void BpBinder::attachObject(

????const void* objectID, void*?object, void* cleanupCookie,

????object_cleanup_func?func)

{

????AutoMutex _l(mLock);

????ALOGV("Attaching object %p to binder %p (manager=%p)", object, this, &mObjects);

????mObjects.attach(objectID,?object, cleanupCookie, func);

}

其中，object_cleanup_func是函數指針，

typedef void (*object_cleanup_func)(const void* id, void* obj, void* cleanupCookie);

?

傳入的值為proxy_cleanup，

staticvoidproxy_cleanup(constvoid* id, void* obj, void* cleanupCookie) { ??? android_atomic_dec(&gNumProxyRefs); ??? JNIEnv* env = javavm_to_jnienv((JavaVM*)cleanupCookie); ??? env->DeleteGlobalRef((jobject)obj); }

?

BpBinder::attachObject方法中又調用了mObjects.attach(objectID,?object, cleanupCookie, func);，mObjects是BpBinder的成員變量。ObjectManager是其內部類。

???????????ObjectManager???????mObjects;

?

void BpBinder::ObjectManager::attach(

????const void* objectID, void*?object, void* cleanupCookie,

????IBinder::object_cleanup_func?func)

{

????entry_t e;

????e.object =?object;

????e.cleanupCookie = cleanupCookie;

????e.func =?func;

?

????if (mObjects.indexOfKey(objectID) >= 0) {

????????ALOGE("Trying to attach object ID %p to binder ObjectManager %p with object %p, but object ID already in use",

????????????????objectID, this,??object);

????????return;

????}

?

????mObjects.add(objectID, e);

}

?

由于mObjects是BpBinder的成員變量，在BpBinder對象析構的時候，mObjects也會析構。

BpBinder::ObjectManager::~ObjectManager()

{

????kill();

}

?

void BpBinder::ObjectManager::kill()

{

????const size_t N = mObjects.size();

????ALOGV("Killing %zu objects in manager %p", N, this);

????for (size_t i=0; i<N; i++) {

????????const entry_t& e = mObjects.valueAt(i);

????????if (e.func != NULL) {

????????????e.func(mObjects.keyAt(i), e.object, e.cleanupCookie);

????????}

????}

?

????mObjects.clear();

}

?

之前傳入的proxy_cleanup會被執行。

staticvoidproxy_cleanup(constvoid* id, void* obj, void* cleanupCookie) { ??? android_atomic_dec(&gNumProxyRefs); ??? JNIEnv* env = javavm_to_jnienv((JavaVM*)cleanupCookie); ??? env->DeleteGlobalRef((jobject)obj); }

在這里，對

585?????????jobject?refObject?= env->NewGlobalRef(

?586?????????????????env->GetObjectField(object, gBinderProxyOffsets.mSelf));

里面的refObject進行了DeleteGlobalRef釋放操作。

?

Google的源碼中考慮到了釋放問題。

所以，之前添加的直接釋放操作

602?????????env->DeleteGlobalRef(refObject);

是有問題的，進而導致了系統不能開機。

?

我們可以在art/runtime/indirect_reference_table.cc:的

IndirectRef IndirectReferenceTable::Add(uint32_t cookie, mirror::Object* obj)方法中添加log打印來對引用數量進行跟蹤：

LOG(ERROR) << "JNI ERROR Test (app bug): " << kind_ << " table , topIndex= " << topIndex??<< "\n";

?

打印結果為

01-01 08:18:58.363 14177-14189/? E/art: JNI ERROR Test (app bug): global reference table , topIndex= 596

01-01 08:18:58.363 14177-14189/? E/art: JNI ERROR Test (app bug): local reference table , topIndex= 0

?

這樣，就可以大致定位到出現大量泄漏的時間點。

?

總結

以上是生活随笔為你收集整理的JNI引用溢出导致的重启问题分析的全部內容，希望文章能夠幫你解決所遇到的問題。

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