Thu Feb 1 21:24:00 GMT 2007
Tom Tromey wrote:
>>>>>> "Marco" == Marco Trudel <firstname.lastname@example.org> 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'.
More information about the Java