On Sep 25, 8:26 pm, Mario Zechner <badlogicga...
> This crashes on the emulator with a sigseg (0xdeadd00d).
It's a deliberate VM abort, because the emulator has CheckJNI
enabled. Production devices don't, so it doesn't cause a failure
there. This is spelled out more explicitly in the "logcat" output,
which you can view with DDMS or "adb logcat".
> The documenation of GetPrimitiveArrayCritical athttp://download-llnw.oracle.com/javase/1.5.0/docs/guide/jni/spec/func
> says that "Inside a critical region, native code must not call other
> JNI functions, or any system call that may cause the current thread to
> block and wait for another Java thread." Now i can interpret this in
> two ways: no JNI calls what so ever, and additionally no blocking
> system calls. Or i could interpret it as no JNI calls that block and
> no system calls that block.
A very limited set of JNI calls is allowed, chosen somewhat
arbitrarily. If you need to use other JNI calls while you have the
region, use the non-Critical variant of the Get call.
These are currently on the "okay" list:
and of course:
(There's a reason why all the String stuff is in there, but it eludes
me at the moment.)
The bottom line is that you shouldn't be doing much of anything while
holding a "critical" region. Querying for a direct buffer address
could involve execution of interpreted code (and, in fact, did, in the
original implementation inherited from Harmony).