On 9.11.2010. 18:43, Nigel Wade wrote:
On 09/11/10 15:29, John Smith wrote:
The crash happens when the JNI library executes memcpy command.
I think the code should be ok because it already works for a long time.
Hmmm, just because it's worked up to now in no way guarantees that the
code is ok. Especially so if the code is ported from a 32bit environment
and compiled for 64bit.
C (assuming it is C) is quite unforgiving of changes in architecture
when certain false assumptions are made (such as using non-pointer types
to store address/pointers and coercing the access). It's "valid" code,
in that the compiler won't necessarily warn you that what you've done is
wrong, and it will compile and run. It just won't work the way you want,
it may work perfectly well for quite some time, overwriting unimportant
code and data - until the day it doesn't work. Maybe that day is today.
You are right.
It seems that some pointers are casted to int which are 2 bytes IIRC.
Since java int is 4 bytes it seems I should change both the applet and
the JNI library.
Do you think the way to go should be to put the java type to long and
the C jint to jlong (__int64)?
This is the sample method declaration:
---------------------------------------------------------------------
JAVA:
public static native void jni_SetMem(int i, byte abyte0[], int j, int k);
C:
SetMem(JNIEnv *pEnv, jclass jObj, jint i_pDest, jbyteArray jArr, jint
iDestOffset, jint iSize)
----------------------------------------------------------------------
Should I change to:
---------------------------------------------------------------------
JAVA:
public static native void jni_SetMem(long i, byte abyte0[], long j, long
k);
C:
SetMem(JNIEnv *pEnv, jclass jObj, jint i_pDest, jbyteArray jArr, jlong
iDestOffset, jlong iSize) //maybe I could leave the size to int, but id
doesn't matter to much
----------------------------------------------------------------------
Thanks again for everyone's help.