Hi, On Fri, 2005-01-14 at 08:48 +0100, Michael Koch wrote: > Am Freitag, 14. Januar 2005 04:49 schrieb Archie Cobbs: > > I got an assertion failure in JC when running a simple Swing app. > > The stack trace showed JC invoking a gtkpeer native method with > > one JNIEnv *, some gtk code, and then gtkpeer calling back into > > JC via the JNI invocation interface with a *different* JNIEnv * > > (belonging to a different thread), i.e.: > > > > ... > > > > Before I go digging into the GTK code, has anyone else seen this? > > > > NOTE: this is with Classpath 0.12, so it might be fixed already > > (has anyone fixed a bug like this lately?) > > > > Thanks for any hints about where to look, etc. > > We triggered exactly the same bug with jamvm lately. Mark found out it > was a bug in jamvm handling JNIEnv* wrongly. I don't know if this was > a fix or a hack. But it helped. Perhaps its a bug in JCVM regarding > handling of JNIEnv.
It was kind of a hack. There was a real bug in how the JNIEnv was stack allocated which meant that even the same thread would not get the same JNIEnv each time. All threads now just get the same (static) JNIEnv which works for now. > The GTK peer saves a JNIEnv* pointer for later use for the callback > methods. This is according to the JNI spec at least not absolutely > correct. The correct way would be to get the current JNIEnv* object > through the global JavaVM object. That is not done yet. Perhaps this > would help you and other VMs. Yes, we should do it this way. We actually already store the_vm (JavaVM) when we initialize gtk+ together with the gdk_env (JNIEnv). Everywhere we use the stored gdk_env we should carefully look whether it is only used from the original gtk+ event thread (directly or through a callback) oitherwise we should get the JNIEnv from the_vm. Note that the gtk+ AWT peer code has recently (after 0.13) changed to use only one event thread. But there are probably code paths that can call into native code from a different (user) thread. I nice addition to the runtime jni support would be a (slow) debugging path to check for this at native method call time. Cheers, Mark
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
