JNI bug?

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.
thanks
Marco
> 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
>