Global reference table overflow

JNI的global reference table overflow是我们系统常见的一种泄露，当发生该问题时抓取hprof是一种非常有效快速定位问题的方法。 抓取hprof功能详细介绍请参考<抓取hprof的debug功能定制>一文，本文主要分享一些案例。

debug 开关

我们增加了抓取hprof的功能，但是需要设置一些property才能使能:
(ro.flyme.published != true && persist.sys.cts_state != true) OR (ro.monkey == true)

快速定位问题

对于AOSP，定位该问题的日志关键字是"global reference table overflow ",类似下面的日志(aosp是fatal的)

10-23 10:43:22.827  1397  7863 E zygote64: JNI ERROR (app bug): global reference table overflow (max=51200)
10-23 10:43:22.827  1397  7863 E zygote64: global reference table dump:
10-23 10:43:22.827  1397  7863 E zygote64:   Last 10 entries (of 51200):
10-23 10:43:22.827  1397  7863 E zygote64:     51199: 0x13dc9508 java.lang.ref.WeakReference (referent is a android.os.BinderProxy)
10-23 10:43:22.827  1397  7863 E zygote64:     51197: 0x13dc8da0 java.lang.ref.WeakReference (referent is a android.os.BinderProxy)
10-23 10:43:22.827  1397  7863 E zygote64:     51196: 0x13d54ff0 java.lang.ref.WeakReference (referent is a android.os.BinderProxy
... ...
10-23 10:43:22.827  1397  7863 E zygote64:   Summary:
10-23 10:43:22.827  1397  7863 E zygote64:     47902 of java.lang.ref.WeakReference (47902 unique instances)
10-23 10:43:22.827  1397  7863 E zygote64:       898 of com.android.server.content.ContentService$ObserverNode$ObserverEntry (898 unique instances)
10-23 10:43:22.827  1397  7863 E zygote64:       444 of android.os.RemoteCallbackList$Callback (444 unique instances)
10-23 10:43:22.827  1397  7863 E zygote64:       314 of java.lang.Class (236 unique instances)
... ...

上述日志告诉我们，有47902个WeakReference对象，最后10个分配的global reference是BinderProxy引用的WeakReference。

对于flyme系统，把JNI ERROR改成了error类型，抓取hprof后主动abort，所以除了看到上述日志外，还会在errormonitor日志中看到fatal exception是abort native crash， crash log如下：

10-23 10:43:26.946 21948 21948 F DEBUG   : pid: 1397, tid: 21928, name: Dump Heap Threa  >>> system_server <<<
10-23 10:43:26.946 21948 21948 F DEBUG   : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
10-23 10:43:26.946 21948 21948 F DEBUG   :     x0   0000000000000000  x1   00000000000055a8  x2   0000000000000006  x3   0000000000000008
10-23 10:43:26.946 21948 21948 F DEBUG   :     x4   0000000000000000  x5   0000000000000000  x6   0000000000000000  x7   00000000001fffff
10-23 10:43:26.946 21948 21948 F DEBUG   :     x8   0000000000000083  x9   0000000010000000  x10  00000072305ff310  x11  29a701d2c38f16c8
10-23 10:43:26.946 21948 21948 F DEBUG   :     x12  29a701d2c38f16c8  x13  0000000000000000  x14  ffffffffffffffdf  x15  00000072f7ffd8a8
10-23 10:43:26.946 21948 21948 F DEBUG   :     x16  0000006148fa9fa8  x17  00000072f7f7f14c  x18  0000007275200080  x19  0000000000000575
10-23 10:43:26.946 21948 21948 F DEBUG   :     x20  00000000000055a8  x21  0000000000000083  x22  0000000000001eb7  x23  00000072750eaf80
10-23 10:43:26.946 21948 21948 F DEBUG   :     x24  00000072749d3cc8  x25  0000007230503000  x26  000000000000c800  x27  0000000000000001
10-23 10:43:26.946 21948 21948 F DEBUG   :     x28  0000000000000000  x29  00000072305ff350  x30  00000072f7f25900
10-23 10:43:26.946 21948 21948 F DEBUG   :     sp   00000072305ff310  pc   00000072f7f25928  pstate 0000000060000000
10-23 10:43:26.956 21948 21948 F DEBUG   : 
10-23 10:43:26.956 21948 21948 F DEBUG   : backtrace:
10-23 10:43:26.956 21948 21948 F DEBUG   :     #00 pc 000000000001e928  /system/lib64/libc.so (abort+120)
10-23 10:43:26.956 21948 21948 F DEBUG   :     #01 pc 0000000000263f50  /system/lib64/libart.so (art::Run(void*)+648)
10-23 10:43:26.956 21948 21948 F DEBUG   :     #02 pc 0000000000077980  /system/lib64/libc.so (__pthread_start(void*)+36)
10-23 10:43:26.956 21948 21948 F DEBUG   :     #03 pc 000000000001fd04  /system/lib64/libc.so (__start_thread+68)

案例分析

案例一　bug#842436

log戳这里
通过日志知道是android.os.BinderProxy引用的WeakReference类型的泄露，通过mat打开hprof
在histogram 页面按照对象个数降序排列除了一些基础类，android.os.BinderProx的对象占用高达47883也非常可以

p1.png

选中该类，右键list objects -> with incomming references 如下图一个个点击看谁引用了这些BinderProxy对象

P2.png

因为总的对象有4万多，所以也只能选择性的查看一些，上图看到点击前几个其mRemote都是IApplicationThread

Proxy的对象，所以首先怀疑它，在Dominator Tree里面搜索IApplicationThread

Proxy对象如下图

P3.png

这里看到一共才83个对象，而由代码可知一个IApplicationThread

Proxy对应一个android.os.BinderProxy最多也就占用83个BinderProxy，所以这里排除。
继续查看BinderProxy其他incomming的引用：

P4.png

这里发现0x18316300对象的引用是一个Hashmap的key, 且需要是696,这里非常可疑说明有一个Hashmap以binderproxy作为key,且至少有696个对象。那么我们看下这个Hashmap被谁引用了点击key 右键－>list objects->with incoming references:

P5.png

这里找到了是PowerManagerService的mAudioMixMap对象我们with outgoing references看下mAudioMixMap　0x17e33af8对象的情况：

P6.png

结合定义：
private HashMap mAudioMixMap = new HashMap<>();
得出结果：
mAudioMixMap保存了BinderProxy作为key,int数组作为value, 这里出现了泄露导致mAudioMixMap有21396个BinderProxy引用没有释放。

案例二　bug#837168
通过日志确认泄露类型

09-16 05:42:21.520  1455  7439 E zygote64: JNI ERROR (app bug): global reference table overflow (max=51200)
09-16 05:42:21.521  1455  7439 E zygote64: global reference table dump:
09-16 05:42:21.521  1455  7439 E zygote64:   Last 10 entries (of 51200):
09-16 05:42:21.521  1455  7439 E zygote64:     51199: 0x13d9f610 com.android.server.am.ContentProviderConnection
09-16 05:42:21.521  1455  7439 E zygote64:     51198: 0x13e40ae8 java.lang.ref.WeakReference (referent is a android.os.BinderProxy)
09-16 05:42:21.521  1455  7439 E zygote64:     51197: 0x13dc9a00 com.android.server.am.ContentProviderConnection
09-16 05:42:21.521  1455  7439 E zygote64:     51196: 0x13d9c638 java.lang.ref.WeakReference (referent is a android.os.BinderProxy)
09-16 05:42:21.521  1455  7439 E zygote64:     51195: 0x13e05a38 com.android.server.am.ContentProviderConnection
09-16 05:42:21.521  1455  7439 E zygote64:     51194: 0x13e40638 java.lang.ref.WeakReference (referent is a android.os.BinderProxy)
09-16 05:42:21.521  1455  7439 E zygote64:     51193: 0x13cbfad8 com.android.server.am.ContentProviderConnection
09-16 05:42:21.521  1455  7439 E zygote64:     51192: 0x13d985c0 java.lang.ref.WeakReference (referent is a android.os.BinderProxy)
09-16 05:42:21.521  1455  7439 E zygote64:     51191: 0x13d9b4f0 com.android.server.am.ContentProviderConnection
09-16 05:42:21.521  1455  7439 E zygote64:     51190: 0x13d96d08 java.lang.ref.WeakReference (referent is a android.os.BinderProxy)
09-16 05:42:21.521  1455  7439 E zygote64:   Summary:
09-16 05:42:21.521  1455  7439 E zygote64:     29925 of java.lang.ref.WeakReference (29925 unique instances)
09-16 05:42:21.521  1455  7439 E zygote64:     18591 of com.android.server.content.ContentService$ObserverNode$ObserverEntry (18591 unique instances)
09-16 05:42:21.521  1455  7439 E zygote64:       812 of android.os.RemoteCallbackList$Callback (812 unique instances)
09-16 05:42:21.521  1455  7439 E zygote64:       314 of java.lang.Class (236 unique instances

通过summay 可以知道泄露的类型是WeakReference和ObserverEntry，根据last 10 entries基本可以确认是BinderProxy引用的WeakReference是ObserverEntry引起。我们接着分析hprof