Re: GTK peer switching JNIEnv *?

[Mark Wielaard]

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