問題描述

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)'

x00000000000000000x100000000000009d6x20000000000000006x30000000000000008

x40000000000000166x50000800000000000x60000007f0a5ab000x7000000000000000c

x80000000000000083x9ffffffffffffffdfx100000000000000000x110000000000000001

x120000000000000010x130000000000000030x14ffffffffffffffffx15ffffffffffffffff

x160000007f069f9ed0x170000007f069a278cx180000000000000000x190000007eddecf4f8

x200000000000000006x210000007eddecf450x22000000000000000dx230000007f05ffe000

x240000007f05f4b52bx250000007f05f85440x260000007eddece4f1x270000007f05ffcda0

x280000000000002ff0x290000007eddece3d0x300000007f0699fbb8

sp0000007eddece3b0pc0000007f069a2794pstate 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/[email protected]@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 {

549if (val == NULL) return NULL;

585jobject refObject = env->NewGlobalRef(

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

587val->attachObject(&gBinderProxyOffsets, refObject,

588jnienv_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，記錄呼叫次數

549if (val == NULL) return NULL;

585jobject refObject = env->NewGlobalRef(

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

587val->attachObject(&gBinderProxyOffsets, refObject,

588jnienv_to_javavm(env), proxy_cleanup);

595

596 scount++;

597 if (scount % 100 == 0)

598 {

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

600 }

601

602 env->DeleteGlobalRef(refObject);

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

604android_atomic_inc(&gNumProxyRefs);

605incRefsCreated(env);

606}

607

608return object;

609 }

編譯執行後，手機卻不能開機了。

分析

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

548 {

549if (val == NULL) return NULL;

585jobject refObject = env->NewGlobalRef(

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

587val->attachObject(&gBinderProxyOffsets, refObject,

588jnienv_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，

static

{

}

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

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會被執行。

static

{

}

在這裡，對

585jobject refObject = env->NewGlobalRef(

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

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

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