[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GTK peer switching JNIEnv *?
From: |
Michael Koch |
Subject: |
Re: GTK peer switching JNIEnv *? |
Date: |
Fri, 14 Jan 2005 08:48:18 +0100 |
User-agent: |
KMail/1.7.1 |
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.:
>
> ...
> #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.
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.
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.
Michael
--
Homepage: http://www.worldforge.org/
- GTK peer switching JNIEnv *?, Archie Cobbs, 2005/01/13
- Re: GTK peer switching JNIEnv *?,
Michael Koch <=
- Re: GTK peer switching JNIEnv *?, Mark Wielaard, 2005/01/14
- Re: GTK peer switching JNIEnv *?, Robert Lougher, 2005/01/14
- Re: GTK peer switching JNIEnv *?, Mark Wielaard, 2005/01/14
- Re: GTK peer switching JNIEnv *?, Robert Lougher, 2005/01/14
- Re: GTK peer switching JNIEnv *?, Michael Koch, 2005/01/14
- Re: GTK peer switching JNIEnv *?, Robert Lougher, 2005/01/14
- Re: GTK peer switching JNIEnv *?, Archie Cobbs, 2005/01/14
- Re: GTK peer switching JNIEnv *?, Robert Lougher, 2005/01/14
- Re: GTK peer switching JNIEnv *?, Chris Gray, 2005/01/14
- Re: GTK peer switching JNIEnv *?, Etienne Gagnon, 2005/01/14