On Feb 4, 2012, at 6:36 PM, NebulaSleuth wrote: > First I seem to get a recurring Global Reference allocation with the *same* > address, that never seems to be deallocated. But the information doesn't > point me to anywhere that I can find in my code. I was hoping someone had > an idea of what a NoClassDefError might be related to.
It's related to "renamed" types, when the managed type differs from the Java type, e.g. Android.Views.View is android.view.View (note the added 's'). To avoid the costs of Reflection, JNIEnv.FindClass(Type) tries the "stupid" Type->string conversion (lowercasing namespace), and if that fails it catches the NoClassDefError and falls back to looking RegisterAttribute.Name and other custom attributes. For many types this doesn't matter, either because they don't use JNIEnv.FindClass(Type) (which is the case for Android.Views.View), or because the default "stringification" operation works. Normally you wouldn't care. Unfortunately, we leak a gref for the NoClassDefError. Oops. More unfortunately, it's not always possible to avoid this, as our default IRunnable implementation (used for method overloads which take an Action instead of an IRunnable) hits this code path. :-( Fortunately, this will be fixed in the forthcoming 4.0.4 release. Sorry, - Jon _______________________________________________ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
