This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: JNI bug?
- From: Tom Tromey <tromey at redhat dot com>
- To: Marco Trudel <mtrudel at gmx dot ch>
- Cc: David Daney <ddaney at avtrex dot com>, GCC Java <java at gcc dot gnu dot org>
- Date: 01 Feb 2007 07:58:45 -0700
- Subject: Re: JNI bug?
- References: <45BE32E7.1030203@gmx.ch> <17854.13647.6940.252691@zebedee.pink> <17854.14774.396746.511071@zebedee.pink> <45BE3BF7.8030605@gmx.ch> <17854.15560.574547.858620@zebedee.pink> <45BE3D97.7000803@gmx.ch> <17854.16053.643339.537856@zebedee.pink> <45BE40C9.3030904@gmx.ch> <45BEDB54.40701@avtrex.com> <45C1D6BB.9080204@gmx.ch>
- Reply-to: tromey at redhat dot com
>>>>> "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