GTK peer switching JNIEnv *?

[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.:

...
#7  0x2808e213 in CallVoidMethod (jenv=0xcd33498, obj=0xd0600b0,
    method=0xd4a10e0) at jni_native.c:442
#8  0x29c32d9b in connect_awt_hook_cb ()
   from /usr/local/lib/classpath/libgtkpeer.so
#9  0x2ae36b1d in g_cclosure_marshal_VOID__VOID ()
   from /usr/local/lib/libgobject-2.0.so.400
#10 0x2ae200f5 in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.400
...
#21 0x2ae345c5 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.400
#22 0x2ab91b24 in gtk_widget_show () from /usr/X11R6/lib/libgtk-x11-2.0.so.400
#23 0x29c3920e in Java_gnu_java_awt_peer_gtk_GtkWindowPeer_nativeSetVisible ()
   from /usr/local/lib/classpath/libgtkpeer.so
#24 0x280b2a73 in ffi_call_SYSV () from /usr/local/lib/libjc.so.1
...

The JNIEnv * passed back in frame #23 is different from the one passed
back in frame #7 (not visible in the trace, but I know it's different).

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.

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com