如何診斷Xamarin Android弱參考表溢出的原因？

我有幾個用戶的報告，說我的應用在大約5分鐘的密集使用後崩潰了。我收到了Google Play上的崩潰日誌，並在下面附上了一個示例。該消息似乎是：如何診斷Xamarin Android弱參考表溢出的原因？

JNI ERROR（APP錯誤）：弱全局引用表溢出（最大值= 51200）」

我不熟悉JNI，並希望使任何意見/解釋/關於如何解決這個問題的建議。可能的原因是我的代碼中的東西沒有被清理乾淨，但是什麼？

，這個問題已經被報告上的設備的Nexus 5.x的，銀河S7和的Nexus 6。

相關代碼可以在我的開源項目中找到：https://gitlab.com/hodgskin-callan/Invention。但是，我沒有最低限度的代碼來重現此問題，並且它不會在我的Nexus 9上重現。我懷疑此問題不會影響大多數Android用戶。

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 
Build fingerprint: 'google/bullhead/bullhead:7.1.1/N4F26T/3687331:user/release-keys' 
Revision: 'rev_1.0' 
ABI: 'arm' 
pid: 10404, tid: 10404, name: .x10host.pathos >>> com.x10host.pathos <<< 
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- 
Abort message: 'art/runtime/indirect_reference_table.cc:132] JNI ERROR (app bug): weak global reference table overflow (max=51200)' 
    r0 00000000 r1 000028a4 r2 00000006 r3 00000008 
    r4 f300558c r5 00000006 r6 f3005534 r7 0000010c 
    r8 00000000 r9 0000000a sl 00001785 fp f0385400 
    ip 0000000b sp ffde7b50 lr f1a065e7 pc f1a08e44 cpsr 200f0010 

backtrace: 
    #00 pc 00049e44 /system/lib/libc.so (tgkill+12) 
    #01 pc 000475e3 /system/lib/libc.so (pthread_kill+34) 
    #02 pc 0001d8a5 /system/lib/libc.so (raise+10) 
    #03 pc 000193f1 /system/lib/libc.so (__libc_android_abort+34) 
    #04 pc 00017034 /system/lib/libc.so (abort+4) 
    #05 pc 0031a5f1 /system/lib/libart.so (_ZN3art7Runtime5AbortEPKc+328) 
    #06 pc 000b5205 /system/lib/libart.so (_ZN3art10LogMessageD2Ev+1132) 
    #07 pc 001bc42b /system/lib/libart.so (_ZN3art22IndirectReferenceTable3AddEjPNS_6mirror6ObjectE+194) 
    #08 pc 0023a097 /system/lib/libart.so (_ZN3art9JavaVMExt16AddWeakGlobalRefEPNS_6ThreadEPNS_6mirror6ObjectE+46) 
    #09 pc 0027f483 /system/lib/libart.so (_ZN3art3JNI16NewWeakGlobalRefEP7_JNIEnvP8_jobject+418) 
    #10 pc 0000de14 /data/app/com.x10host.pathos-2/lib/arm/libmonodroid.soapp/com.x10host.pathos-2/lib/arm/libmonodroid.so

來源

2017-04-14 Callan Hodgskin

有一整段關於gref日誌記錄的文檔，您可以通過它來跟蹤它：https://developer.xamarin.com/guides/android/troubleshooting/troubleshooting/#Global_Reference_Messages –

謝謝，我已閱讀本文並啓用日誌記錄。它幾乎整個時間都表示gwrefc 0。我希望看到它隨着時間的推移而增長。你知道是否有辦法在運行時查詢grefc和gwrefc的當前狀態？我可以給我的用戶定製一個APK進行測試。 –

你可以設置一個環境屬性：https://developer.xamarin.com/guides/android/advanced_topics/environment/#Xamarin.Android_System_Properties然後在應用程序崩潰時向用戶請求一個'adb logcat'？如果你無法在本地複製，這會有點困難。 –

有關於這個問題很長，但非常有用的一條文檔編制的位置：

https://developer.xamarin.com/guides/android/troubleshooting/troubleshooting/#Global_Reference_Messages

對於第一次通過，你應該嘗試通過.txt文件，以使系統屬性，有它的Build Action設置爲$(AndroidEnvironment)：

即debug.mono.log gref

https://developer.xamarin.com/guides/android/advanced_topics/environment/#Xamarin.Android_System_Properties

然後，您將從包含此日誌記錄的設備獲取adb logcat。

然而，如果不工作，你贊成：

你應該能夠直接通過查詢：

Java.Interop.JniRuntime.CurrentRuntime.GlobalReferenceCount

Java.Interop.JniRuntime.CurrentRuntime.WeakGlobalReferenceCount

當地的引用也跟蹤了Java.Interop.JniEnvironment.LocalReferenceCount這是一個線程本地值。

來源

2017-04-14 15:18:05

當我閱讀那篇文章時，我沒有看到以編程方式查詢部分！雖然，我認爲WeakGlobalReferenceCount總是在Xamarin Android上返回-1。第81行：https：//github.com/xamarin/xamarin-android/blob/master/src/Mono.Android/Android.Runtime/AndroidRuntime.cs。我查了一下，因爲我在Nexus 9上得到-1。 –

這是因爲我添加了該部分。我確實認爲-1可能是一個問題。您應該可以使用'LocalReferenceCount'，但是https://github.com/xamarin/java.interop/blob/a1d3ecc8ba6e67b96ae1c633194b0e78c2ac5c23/src/Java.Interop/Java.Interop/JniEnvironment.cs#L35-L37 –

好吧，我沒有結論，但我確實收到了一位用戶的新反饋。他觀察到，當grefc超過46,000時，應用程序崩潰。當我重現Nexus 9上的情況時，該應用不會崩潰，並且grefc重置爲約6000。有沒有問題的代碼與grefc清理有關？ –

如何診斷Xamarin Android弱參考表溢出的原因？

回答

相關問題