JNI bug?

Thu Feb 1 17:09:00 GMT 2007

>>>>> "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().
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