JNI bug?

Marco Trudel mtrudel@gmx.ch
Thu Feb 1 21:24:00 GMT 2007

Tom Tromey wrote:
>>>>>> "Marco" == Marco Trudel <mtrudel@gmx.ch> writes:
> Marco> Any other ideas where to look? I don't know where happens what when
> Marco> calling a method over jni.
> There are 2 cases.
> For a call from a compiled class (i.e. one compiled with -fjni), the
> compiler emits a small stub that looks up the user's JNI function,
> marshals the arguments, sets up the JNI stack frame, and makes the
> call.  See gcc/java/expr.c:build_jni_stub().

All right! Hardcore tree creation ;-)
Unfortunately I do not have time for learning this tree structure now. 
So I'll stick with my library fix and add a bugreport so that the 
inconsistency won't be forgotten.


> For methods in an interpreted class something similar happens at
> runtime, using libffi.  See libjava/jni.cc:_Jv_JNIMethod::call().
>>> for (int i = 0; i < arg_types->length; ++i)
>>> {
>>> values[i].j = 0; // Clean garbage out of the union so that buggy
>>> JNI code looking for jint where it should be looking for jboolean
>>> will work.
> Marco> I think it's not that easy. It should be correctly set after the
> Marco> boolean. If b then 1 else 0. So the suggested malloc from Tom also
> Marco> won't work...
> His idea is to clear the argument buffer before marshaling arguments
> into it, thus ensuring that unused bits are all '0'.
> Tom

More information about the Java mailing list