This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: JNI bug?


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]