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

Question

A few times a day, an ArcGIS Runtime app spontaneously dies while not doing much of anything.

This error is in logcat.

According to my knowledge I have ZERO (0) control over the JNI global reference table. ArcGIS runtime is the only one making JNI calls.

What can I do to prevent this?

If interested, this is a longer dump.

02-12 14:47:01.807 29469-30370/com.. A/art: art/runtime/indirect_reference_table.cc:128] JNI ERROR (app bug): weak global reference table overflow (max=51200)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128] weak global reference table dump:
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]   Last 10 entries (of 51200):
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]     51199: 0x131f3d30 java.lang.Thread
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]     51198: 0x131f3ca0 java.lang.Thread
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]     51197: 0x131f3c10 java.lang.Thread
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]     51196: 0x131f3b80 java.lang.Thread
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]     51195: 0x131f3af0 java.lang.Thread
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]     51194: 0x131f3a60 java.lang.Thread
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]     51193: 0x131f39d0 java.lang.Thread
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]     51192: 0x131f3940 java.lang.Thread
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]     51191: 0x131f38b0 java.lang.Thread
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]     51190: 0x131f3820 java.lang.Thread
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]   Summary:
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         9 of com.esri.arcgisruntime.internal.jni.CoreVector (9 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         3 of com.esri.arcgisruntime.internal.jni.CorePlatformHelpersProvider (1 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         4 of com.esri.arcgisruntime.internal.jni.CoreMap (1 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         3 of com.esri.arcgisruntime.internal.jni.CoreBasemap (1 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         1 of com.raizlabs.android.dbflow.structure.database.transaction.DefaultTransactionQueue
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]        36 of com.esri.arcgisruntime.internal.jni.CorePictureMarkerSymbol (12 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         3 of com.esri.arcgisruntime.internal.jni.CoreGeodatabaseFeatureTable (1 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         4 of com.esri.arcgisruntime.internal.jni.CoreFeatureLayer (1 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]        12 of com.esri.arcgisruntime.internal.jni.CoreArcGISVectorTiledLayer (4 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         9 of com.esri.arcgisruntime.internal.jni.CoreMapView (1 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         3 of com.esri.arcgisruntime.internal.jni.CoreLocationDisplay (1 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         1 of android.opengl.GLSurfaceView
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         1 of android.opengl.GLSurfaceView$GLThread
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         2 of com.esri.arcgisruntime.internal.jni.CoreLocationDataSource (1 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         3 of com.esri.arcgisruntime.internal.jni.CoreLocatorTask (1 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         5 of com.bumptech.glide.load.engine.executor.GlideExecutor$DefaultThreadFactory$1 (5 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]      1983 of java.lang.Thread (1983 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]     10309 of java.lang.Class (10308 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         5 of byte[] (2496 elements) (5 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         3 of byte[] (8976 elements) (3 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         1 of byte[] (12288 elements)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         5 of byte[] (16384 elements) (5 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         4 of byte[] (17920 elements) (4 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         1 of byte[] (24064 elements)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         1 of byte[] (26240 elements)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         1 of byte[] (30720 elements)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         9 of byte[] (36864 elements) (9 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]        29 of byte[] (46656 elements) (29 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         4 of byte[] (50176 elements) (4 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         1 of byte[] (57344 elements)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         1 of byte[] (57408 elements)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         2 of byte[] (61952 elements) (2 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         2 of byte[] (62500 elements) (2 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]        25 of byte[] (65536 elements) (25 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         3 of byte[] (82944 elements) (3 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         2 of byte[] (84480 elements) (2 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         3 of byte[] (141312 elements) (3 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         1 of byte[] (146432 elements)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         3 of byte[] (147456 elements) (3 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         4 of byte[] (160000 elements) (4 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         4 of byte[] (195536 elements) (4 unique instances)
02-12 14:47:01.807 29469-30370/com.. A/art: art..cc:128]         1 of byte[] (305152 elements)
02-12 14:47:01.808 29469-30370/com.. A/art: art..cc:128]         5 of byte[] (478864 elements) (5 unique instances)
02-12 14:47:01.808 29469-30370/com.. A/art: art..cc:128]         1 of java.lang.ThreadGroup
02-12 14:47:01.808 29469-30370/com.. A/art: art..cc:128]        47 of java.lang.DexCache (47 unique instances)
02-12 14:47:01.808 29469-30370/com.. A/art: art..cc:128]         6 of dalvik.system.PathClassLoader (2 unique instances)
02-12 14:47:01.808 29469-30370/com.. A/art: art..cc:128]       150 of android.view.RenderNode (150 unique instances)
02-12 14:47:01.808 29469-30370/com.. A/art: art..cc:128]

ForrestKaye · Answer

For you or anyone needing this, I believe the true source of the issue and solution had more to do with implementing an expected method that cleared or reset some memory or pointer when iterating.  I can't remember the exact method but I believe it was some java inherited method.  So it was less of an SDK issue and more of a proper Java iteration implementation if I'm not mistaken.

khalligan · Answer

Looks like this issue is still present in ArcGIS Runtime SDK for Android version 100.15.  We are seeing this issue with the Android Runtime SDK version 100.15 when trying to iterate through query results from a local offline geodatabase with 5,000+ records in the result.  The nature of error is especially challenging as it does not throw an exception and thus cannot be handled properly, and in our case does not occur in debug mode thus was not found during initial development and is slower to debug.

It would be great to see this issue addressed, or hear of workarounds that other developers have found.  It seems that the only workaround it to limit, in advance, the number of records returned from a query.  This of course requires making multiple queries - something that the SDK should be able to prevent.  Of course it would be possible to query via a standard SQLite library, which would handle large queries correctly, but we are trying to use the ArcGIS Runtime SDK for Android for all offline geodatabase access.

ForrestKaye · Answer

I am also seeing this. It happens when I am running a rather large amount of queries on an offline database. I am wondering if there is a solution that involves running the queries differently. I am using 100.11 version of the sdk. GeodatabaseFeatureTable gdbFeatureTable = (GeodatabaseFeatureTable) featureTable; boolean hasAttachments = gdbFeatureTable.hasAttachments(); if (hasAttachments) { long featureCount = gdbFeatureTable.getTotalFeatureCount(); // in the thousands ListenableFuture featureQueryResultFuture = featureTable.queryFeaturesAsync(query); featureQueryResultFuture.addDoneListener(new Runnable() { @Override public void run() { FeatureQueryResult featureQueryResult = featureQueryResultFuture.get(); Iterator features = featureQueryResult.iterator(); while (features.hasNext()) { final Feature feature = features.next(); ArcGISFeature featureAGS = (ArcGISFeature) feature; ListenableFuture> attachmentResults = featureAGS.fetchAttachmentsAsync(); // Error seems to be thrown from here } } }); }