classpath
[Top][All Lists]
Advanced

[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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]