global reference table overflow

https://blog.csdn.net/a396604593/article/details/105771093

ErrorLog:

    04-26 18:20:16.112 12201 12201 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

    04-26 18:20:16.112 12201 12201 F DEBUG   : Build fingerprint:

    'htc/ocmdugl_00401/htc_ocmdugl:9/PQ2A.190205.003/1076299.1:user/release-keys'

    04-26 18:20:16.113 12201 12201 F DEBUG   : Revision: '0'

    04-26 18:20:16.113 12201 12201 F DEBUG   : ABI: 'arm64'

    04-26 18:20:16.113 12201 12201 F DEBUG   : pid: 1773, tid: 7880, name: Binder:1773_20  >>> system_server <<<

    04-26 18:20:16.113 12201 12201 F DEBUG   : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------

    04-26 18:20:16.113 12201 12201 F DEBUG   : Abort message: 'java_vm_ext.cc:676] JNI ERROR (app bug): global reference table

    overflow (max=51200)global reference table dump:'

1、百度搜尋global reference table overflow (max=51200)

JNI層coding經常會遇到ReferenceTable overflow（引用表溢出造成的崩潰）問題，特别是當jni函數被反複調用上千上萬次的時候。

2、log中搜尋java_vm_ext.cc:676發現

48560 of com.android.server.am.PendingIntentRecord (48560 unique instances)

max=51200,而PendingIntentRecord就有 48560個。

這時如果能抓取system_server的hprof檔案進行檢視，會很友善的看出哪個對象導緻的記憶體溢出。

3、如果沒有hprof檔案，隻看log檔案。

從上述log中得到pid: 1773, tid: 7880, name: Binder:1773_20，在log中

搜尋Binder:1773_20:

…

04-26 18:20:15.119  1773  7880 F system_server: runtime.cc:558] "Binder:1773_20" prio=5 tid=135 Runnable

…

檢視log發現

    04-26 18:20:15.121  1773  7880 F system_server: runtime.cc:558]   at android.os.Parcel.nativeWriteStrongBinder(Native method)

    04-26 18:20:15.121  1773  7880 F system_server: runtime.cc:558]   at ndroid.os.Parcel.writeStrongBinder(Parcel.java:737)

    04-26 18:20:15.121  1773  7880 F system_server: runtime.cc:558]   at android.app.IActivityManager$Stub.onTransact$getIntentSender$(IActivityManager.java:10438)

    04-26 18:20:15.121  1773  7880 F system_server: runtime.cc:558]   at android.app.IActivityManager$Stub.onTransact(IActivityManager.java:775)

    04-26 18:20:15.121  1773  7880 F system_server: runtime.cc:558]   at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:3435)

    04-26 18:20:15.121  1773  7880 F system_server: runtime.cc:558]   at android.os.Binder.execTransact(Binder.java:740)

發現bind相關操作導緻，這個是導緻崩潰的最後一根稻草

4、搜尋7880，

發現activityManager多次bindService、unbindService。

導緻system_server的記憶體溢出。

源碼分析:

JNI ERROR (app bug): global reference table overflow (max=51200)

全局引用表溢出,說明全局對象個數太多

報錯的行數java_vm_ext.cc:676

相關代碼:

    jobject JavaVMExt::AddGlobalRef(Thread* self, ObjPtr<mirror::Object> obj) {

      // Check for null after decoding the object to handle cleared weak globals.

      if (obj == nullptr) {

        return nullptr;

      }

      IndirectRef ref;

      std::string error_msg;

      {

        WriterMutexLock mu(self, *Locks::jni_globals_lock_);

        ref = globals_.Add(kIRTFirstSegment, obj, &error_msg);//error_msg的來源

      }

      if (UNLIKELY(ref == nullptr)) {

        LOG(FATAL) << error_msg;//報錯的行數

        UNREACHABLE();

      }

      CheckGlobalRefAllocationTracking();

      return reinterpret_cast<jobject>(ref);

    }

可以看出是globals_.Add中出了問題

indirect_reference_table.cc#Add中

    if (top_index == max_entries_) {//下标是否達到最大值

        if (resizable_ == ResizableCapacity::kNo) {//是否可以調整表的容量

          std::ostringstream oss;

          oss << "JNI ERROR (app bug): " << kind_ << " table overflow "

              << "(max=" << max_entries_ << ")"

              << MutatorLockedDumpable<IndirectReferenceTable>(*this);

          *error_msg = oss.str();

          return nullptr;

    }

其中max_entries_目前值定義為51200, java_vm_ext.cc中定義了最大值如下:

static constexpr size_t kGlobalsMax = 51200;  // Arbitrary sanity check. (Must fit in 16 bits.)

每個Binder實體在jni層都會對應一個JavaBBinder執行個體.

bindServer時,為什麼在art中會存在一個全局引用對象?

調用過程

<1>writeStrongBinder(IBinder val)

<2>android_os_Parcel_writeStrongBinder()

<3>ibinderForJavaObject(env, object)

<4> JavaBBinderHolder::get(env, obj)

<5> new JavaBBinder(env, obj);

<6> mObject(env->NewGlobalRef(object)

<7> JNI::NewGlobalRef()

<8> art::JavaVMExt::AddGlobalRef()

<9> art::IndirectReferenceTable::Add()

參考連結:

問題分析過程:

https://www.jianshu.com/p/bcc5462a78ce

https://blog.csdn.net/chi_wy/article/details/83104748

抓取hprof檔案:

https://blog.csdn.net/happy_develop_/article/details/79099227

bindService啟動Service與Binder服務實體的流程:android-N的

https://www.jianshu.com/p/9128f1b65586

jni文檔:

https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html

————————————————

版權聲明：本文為CSDN部落客「縱容_伊人倩影」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。

原文連結：https://blog.csdn.net/a396604593/article/details/105771093