Re: GTK peer switching JNIEnv *?

[Archie Cobbs]

Michael Koch wrote:
> > 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).
>
> 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.

I'm fairly certain that JC is not mishandling the JNIEnv *. Also,
it is obvious from inspecting the stack that the JNIEnv * changed
when going through the gtkpeer native code.

Apparently the GTK code is saving the JNIEnv * in one thread,
and then using it in a different thread. My guess is that the
callback function is being called by some other thread within
GTK that's not attached to the VM, then picking up the JNIEnv *
that was saved previously in a different (non-callback) thread.

If so, this is completely broken, as JNIEnv *'s are thread specific.
However, the AttachCurrentThread() can be used to attach a new thread
and get a new one for a thread if needed.

Perhaps the GTK peer should use pthread_[sg]etspecific() to store
the JNIEnv * instead of whatever it's currently doing. This would
ensure that the rigth JNIEnv * got used. However, the GTK stuff
would also then have to keep track attaching and detaching threads
to the VM as necessary.

-Archie

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