Thanks for the clarification. Most helpful. In that case, if the stacktrace in question is the point of failure, then, looking at the error message, something must be disposing of the windowManager object or its DefaultDisplay property. The DisplayMetrics object is a brand new locally declared object so it can't be that. I don't believe I'm using either of these anywhere else in my code and I'm pretty sure I'm only calling the ThemedResourceAttribute method from the UI thread, so it should surely be threadsafe. I'm certainly not explicitly disposing of them anywhere that I know of, so it does sound rather like something internal to monodroid is killing a gref out from under my feet :(
Incidentally, I saw another "impossible" stacktrace today whilst trying to recreate the gref issue with logging enabled. (by "impossible", I mean a stacktrace which could never bubble up to an unhandled exception in the runtime as there was a catch all exceptions statement at the root of the thread's run method). So there must be something still not quite right in the gc... (although it is definitely _much_ more stable since 4.2.3/4.2.4!!!). As always, I'm afraid this is all code that relies on upnp devices kicking around on the network and so it will be almost impossible for me to give you a repro app :( Sorry to bear yet more bad tidings to Kumpera! Cheers Iain -- View this message in context: http://mono-for-android.1047100.n5.nabble.com/jni-error-with-4-2-4-on-jellybean-tp5711456p5711517.html Sent from the Mono for Android mailing list archive at Nabble.com. _______________________________________________ Monodroid mailing list [email protected] UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
