Global References (Explosion) [Solved]

Hello MonoGame devs. I’ve been away from MonoGame for a bit and I’m diving back in.

I downloaded the latest MonoGame/Xamarin and when I make a new project from scratch and run it, I’m getting a crash in both debug and release mode.

Within about 30 seconds I see the logcat printing some lines before it explodes.

D/dalvikvm(18492): GREF has increased to 2001

I think it’s telling me the Global References increased to 2001.

Here’s more of the log.

GREF has increased to 1901
GREF has increased to 2001
JNI global reference table (0x67465420) dump:
  Last 10 entries (of 2001):
     2000: 0x41cd31e0 java.lang.Class<>
     1999: 0x42ffc2d8 java.lang.NoClassDefFoundError
     1998: 0x42ffbf58 java.lang.NoClassDefFoundError
     1997: 0x42ffbbd8 java.lang.NoClassDefFoundError
     1996: 0x42ffb858 java.lang.NoClassDefFoundError
     1995: 0x42ffb4d8 java.lang.NoClassDefFoundError
     1994: 0x42ffb158 java.lang.NoClassDefFoundError
     1993: 0x42ffadd8 java.lang.NoClassDefFoundError
     1992: 0x42ffaa58 java.lang.NoClassDefFoundError
     1991: 0x42ffa6d8 java.lang.NoClassDefFoundError
      160 of java.lang.Class (124 unique instances)
        2 of java.lang.String (2 unique instances)
     1771 of java.lang.NoClassDefFoundError (1771 unique instances)

Now I think that’s telling me that something in the default templates is not finding an expected class and maybe it’s moving the class not found reference to global references over and over.

Funny that I know what that means now. I’ve grown from padawin and know JNI kung fu.

Is this a new issue and has the rest of the MonoGame/OUYA community updates to the latest.

I need to get in touch with some Gurus and get the code updated and maybe let Xamarin know.

Thanks and it’s good to be back!

I haven’t seen that myself, but then I haven’t created a new project for quite a while. There has also been some restructuring happening in MonoGame recently, but that should not have had any effect on GREFs. I’ll have a look when I get home tonight to see if I can find anything.

I filed a bug with Xamarin, so at least the log will contain what class it was looking for with the class not found exception occurs in JNI.

Another issue is when the global reference count causes the stackdump, if you were debugging in Visual Studio then you get stuck debugging on that line, and VS is no longer responsive.

Still blocked by the GREF leak issue on launch for Android and OUYA builds.

Excessive JNI global references (2001)
VM aborting

at <0xffffffff>
  at (wrapper managed-to-native) object.wrapper_native_0x407b4219 (intptr,intptr) <0xffffffff>
  at Android.Runtime.JNIEnv.NewGlobalRef (intptr) <0x00043>
  at Android.Runtime.JNIEnv.FindClass (string) <0x0020f>
  at Android.Runtime.JNIEnv.AllocObject (string) <0x0001f>
  at Android.Runtime.JNIEnv.StartCreateInstance (string,string,Android.Runtime.JValue[]) <0x0002f>
  at Java.Lang.Thread/RunnableImplementor…ctor (System.Action,bool) <0x0004f>
  at Android.OS.Handler.Post (System.Action) <0x0002b>
  at Android.App.SyncContext.Send (System.Threading.SendOrPostCallback,object) <0x001a7>
  at OpenTK.Platform.Android.AndroidGameView.m__1 (object) <0x0021b>
  at System.Threading.Tasks.TaskActionInvoker/ActionObjectInvoke.Invoke (System.Threading.Tasks.Task,object,System.Threading.Tasks.Task) <0x0

at System.Threading.Tasks.Task.InnerInvoke () <0x0007f>
  at System.Threading.Tasks.Task.ThreadStart () <0x0021b>
  at System.Threading.Tasks.Task.Execute () <0x00013>
  at System.Threading.Tasks.TpScheduler.TaskExecuterCallback (object) <0x0004b>
  at (wrapper runtime-invoke) .runtime_invoke_void__this___object (object,intptr,intptr,intptr) <0xffffffff>

Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.

Here’s a better stack trace when compiled against master.

D/dalvikvm(28316): GREF has increased to 2001
W/dalvikvm(28316): JNI global reference table (0x67878008) dump:
W/dalvikvm(28316):   Last 10 entries (of 2001):
W/dalvikvm(28316):      2000: 0x41ce5708 java.lang.Class<>
W/dalvikvm(28316):      1999: 0x41d78368
W/dalvikvm(28316):      1998: 0x41d78390 android.os.Handler
W/dalvikvm(28316):      1997: 0x41d785a0 java.lang.NoClassDefFoundError
W/dalvikvm(28316):      1996: 0x41d78220 java.lang.NoClassDefFoundError
W/dalvikvm(28316):      1995: 0x41d77ea0 java.lang.NoClassDefFoundError
W/dalvikvm(28316):      1994: 0x41d77b20 java.lang.NoClassDefFoundError
W/dalvikvm(28316):      1993: 0x41d777a0 java.lang.NoClassDefFoundError
W/dalvikvm(28316):      1992: 0x41d77420 java.lang.NoClassDefFoundError
W/dalvikvm(28316):      1991: 0x41d770a0 java.lang.NoClassDefFoundError
W/dalvikvm(28316):   Summary:
W/dalvikvm(28316):       159 of java.lang.Class (125 unique instances)
W/dalvikvm(28316):         2 of java.lang.String (2 unique instances)
W/dalvikvm(28316):      1777 of java.lang.NoClassDefFoundError (1777 unique instances)
W/dalvikvm(28316):        13 of java.lang.ref.WeakReference (13 unique instances)
W/dalvikvm(28316):         1 of dalvik.system.PathClassLoader
W/dalvikvm(28316):         1 of android.content.res.AssetManager
W/dalvikvm(28316):         1 of android.view.Display
W/dalvikvm(28316):         1 of
W/dalvikvm(28316):         7 of (1 unique instances)
W/dalvikvm(28316):         1 of android.content.res.Configuration
W/dalvikvm(28316):         1 of$ApplicationThread
W/dalvikvm(28316):         1 of android.os.Handler
W/dalvikvm(28316):         1 of$ApplicationContentResolver
W/dalvikvm(28316):         1 of android.content.ContentProvider$Transport
W/dalvikvm(28316):         2 of$ReceiverDispatcher$InnerReceiver (2 unique instances)
W/dalvikvm(28316):         1 of android.util.DisplayMetrics
W/dalvikvm(28316):         1 of android.content.res.Resources
W/dalvikvm(28316):         1 of$StringUri
W/dalvikvm(28316):         1 of android.os.Looper
W/dalvikvm(28316):         1 of android.view.ViewRootImpl$W
W/dalvikvm(28316):         1 of android.view.SurfaceView$4
W/dalvikvm(28316):         1 of android.view.SurfaceView$MyWindow
W/dalvikvm(28316):         1 of android.view.Window$LocalWindowManager
W/dalvikvm(28316):         1 of android.view.accessibility.AccessibilityManager$1
W/dalvikvm(28316):         1 of android.view.inputmethod.InputMethodManager$1
W/dalvikvm(28316):         1 of android.view.inputmethod.InputMethodManager$ControlledInputConnectionWrapper
W/dalvikvm(28316):         1 of
W/dalvikvm(28316):         1 of
W/dalvikvm(28316):         6 of (6 unique instances)
W/dalvikvm(28316):         2 of (2 unique instances)
W/dalvikvm(28316):         2 of (2 unique instances)
W/dalvikvm(28316):         1 of android.view.ViewRootImpl$WindowInputEventReceiver
W/dalvikvm(28316):         1 of
W/dalvikvm(28316):         1 of virtualcontroller.Activity1
W/dalvikvm(28316):         1 of microsoft.xna.framework.OrientationListener
W/dalvikvm(28316):         1 of microsoft.xna.framework.ScreenReceiver
W/dalvikvm(28316):         1 of
W/dalvikvm(28316):         1 of android.view.Choreographer$FrameDisplayEventReceiver
W/dalvikvm(28316):         1 of microsoft.xna.framework.AndroidGameWindow
W/dalvikvm(28316):         1 of
E/dalvikvm(28316): Excessive JNI global references (2001)
E/dalvikvm(28316): VM aborting
E/mono-rt (28316): Stacktrace:
E/mono-rt (28316):
E/mono-rt (28316):   at <0xffffffff>
E/mono-rt (28316):   at (wrapper managed-to-native) object.wrapper_native_0x407b4219 (intptr,intptr) <IL 0x00026, 0xffffffff>
E/mono-rt (28316):   at Android.Runtime.JNIEnv.NewGlobalRef (intptr) [0x00000] in /Users/builder/data/lanes/monodroid-mlion-monodroid-4.12-series/7f0e3d3c/sourc
E/mono-rt (28316):   at Android.Runtime.JNIEnv.FindClass (string) [0x0008e] in /Users/builder/data/lanes/monodroid-mlion-monodroid-4.12-series/7f0e3d3c/source/m
E/mono-rt (28316):   at Android.Runtime.JNIEnv.AllocObject (string) [0x00000] in /Users/builder/data/lanes/monodroid-mlion-monodroid-4.12-series/7f0e3d3c/source
E/mono-rt (28316):   at Android.Runtime.JNIEnv.StartCreateInstance (string,string,Android.Runtime.JValue[]) [0x0000a] in /Users/builder/data/lanes/monodroid-mli
E/mono-rt (28316):   at Java.Lang.Thread/RunnableImplementor…ctor (System.Action,bool) [0x00000] in /Users/builder/data/lanes/monodroid-mlion-monodroid-4.12-se
E/mono-rt (28316):   at Android.OS.Handler.Post (System.Action) [0x00000] in /Users/builder/data/lanes/monodroid-mlion-monodroid-4.12-series/7f0e3d3c/source/mon
E/mono-rt (28316):   at Android.App.SyncContext.Send (System.Threading.SendOrPostCallback,object) [0x0004a] in /Users/builder/data/lanes/monodroid-mlion-monodro
E/mono-rt (28316):   at OpenTK.Platform.Android.AndroidGameView.m__1 (object) [0x00082] in /Users/builder/data/lanes/monodroid-mlion-monodroid-4.12
E/mono-rt (28316):   at System.Threading.Tasks.TaskActionInvoker/ActionObjectInvoke.Invoke (System.Threading.Tasks.Task,object,System.Threading.Tasks.Task) <IL
0x00007, 0x00063>
E/mono-rt (28316):   at System.Threading.Tasks.Task.InnerInvoke () <IL 0x0003f, 0x00123>
E/mono-rt (28316):   at System.Threading.Tasks.Task.ThreadStart () <IL 0x00098, 0x004b7>
E/mono-rt (28316):   at System.Threading.Tasks.Task.Execute () <IL 0x00001, 0x00043>
E/mono-rt (28316):   at System.Threading.Tasks.TpScheduler.TaskExecuterCallback (object) <IL 0x00008, 0x0008f>
E/mono-rt (28316):   at (wrapper runtime-invoke) .runtime_invoke_void__this___object (object,intptr,intptr,intptr) <IL 0x00052, 0xffffffff>
E/mono-rt (28316):
E/mono-rt (28316): =================================================================
E/mono-rt (28316): Got a SIGSEGV while executing native code. This usually indicates
E/mono-rt (28316): a fatal error in the mono runtime or one of the native libraries
E/mono-rt (28316): used by your application.
E/mono-rt (28316): =================================================================

Do you have a small project that reproduces this?
I ran master against Android just a few days ago without issues.

What device/Android version too might be useful.

I tried all the previous MonoGame versions and I’m running a custom build. No repro project is necessary because the default empty project reproduces the issue. The custom Android build is missing some unknown class and MonoGame/Android keeps looking for that class (without logging what it is) and runs out of global memory.

I suspect code like this.

var getId = jni->findClass(“some class I want to know”);
// throws exception, but code doesn’t check for it
// use that class, gets exception
// and repeat, try try try again

I’m going to try a different Android build, known to work which should fix my issue.

Solved my issue. I was on an engineering build instead of a user build. My bad.

I’d be interested in still knowing which class is missing…

What is an Engineering build?

Just a custom build of AOSP labelled “engineering”.

This issue is totally resolved and MonoGame is working great.