Android KitKat emulator native library JNI ERROR (app bug)

Question

While testing my app with Android 4.4.2 API level 19 emulator, first call to native code causes a crash. This is the logcat:

01-29 12:12:32.639: E/ALLOC(1232): Requiring 1228800bytes
01-29 12:12:32.639: D/dalvikvm(1232): Trying to load lib /data/app-lib/it.jcsoftmobile.snailcamera.snailcamerapro-1/liblowlevelpixelworks.so 0xb4cd9cc8
01-29 12:12:32.639: D/dalvikvm(1232): Added shared lib /data/app-lib/it.jcsoftmobile.snailcamera.snailcamerapro-1/liblowlevelpixelworks.so 0xb4cd9cc8
01-29 12:12:32.639: D/dalvikvm(1232): No JNI_OnLoad found in /data/app-lib/it.jcsoftmobile.snailcamera.snailcamerapro-1/liblowlevelpixelworks.so 0xb4cd9cc8, skipping init
01-29 12:12:32.679: E/dalvikvm(1232): JNI ERROR (app bug): negative buffer capacity: -5457750921690562560
01-29 12:12:32.679: I/dalvikvm(1232): "main" prio=5 tid=1 RUNNABLE
01-29 12:12:32.679: I/dalvikvm(1232):   | group="main" sCount=0 dsCount=0 obj=0xb4a2aca8 self=0xb70c4380
01-29 12:12:32.689: I/dalvikvm(1232):   | sysTid=1232 nice=0 sched=0/0 cgrp=apps handle=-1225698988
01-29 12:12:32.689: I/dalvikvm(1232):   | state=R schedstat=( 1140000000 1520000000 1339 ) utm=83 stm=31 core=0
01-29 12:12:32.729: I/dalvikvm(1232):   at it.jcsoftmobile.snailcamera.ImageLab.NativeAlloc(Native Method)

This is the logcat of the same piece of code, same app, same screen-size emulator, ... the only thing that differs is Android version (4.3):

01-28 19:52:51.543: E/ALLOC(12661): Requiring 1228800bytes
01-28 19:52:51.563: D/dalvikvm(12661): Trying to load lib /data/app-lib/it.jcsoftmobile.snailcamera.snailcamerapro-1/liblowlevelpixelworks.so 0x416e2fd0
01-28 19:52:51.613: D/dalvikvm(12661): Added shared lib /data/app-lib/it.jcsoftmobile.snailcamera.snailcamerapro-1/liblowlevelpixelworks.so 0x416e2fd0
01-28 19:52:51.613: D/dalvikvm(12661): No JNI_OnLoad found in /data/app-lib/it.jcsoftmobile.snailcamera.snailcamerapro-1/liblowlevelpixelworks.so 0x416e2fd0, skipping init
01-28 19:52:51.922: D/dalvikvm(12661): GC_FOR_ALLOC freed 68K, 4% free 3447K/3584K, paused 302ms, total 303ms
01-28 19:52:51.922: I/dalvikvm-heap(12661): Grow heap (frag case) to 3.865MB for 460816-byte allocation

I read something about ART vm, but i think this is not the case, because logcat explicitly tags both outputs as "dalvikvm".

My app was running ok on every tested devices and emulators, starting from GB 2.3.3 to JB 4.3, KitKat is the first version that gave me problems.

Maybe KitKat has a different loadLibrary management? Should i implement (i dunno how!) JNI_OnLoad?

Any idea?

EDIT

I tested my app on a Nexus 7 with KK 4.4.2, and it's working fine.

Here's the C code that generates the exception:

jobject Java_my_package_NativeAlloc(JNIEnv* env, jlong numBytes) {
    void *ptr = (char*)malloc(numBytes);
    return (*env)->NewDirectByteBuffer(env, ptr, numBytes);
}

and here's the Java code that calls it:

public native static ByteBuffer NativeAlloc(int size);

There is of course an issue, as Java int size (32-bit) becomes a JNI jlong numBytes (64-bit), my fault. But why this code worked fine until 4.4.2 emulator?

Answer 1

Your function prototype is incorrect, causing your arguments to be intermixed in a platform-dependent way and the requested size to be potentially corrupted.

public native static ByteBuffer NativeAlloc(int size);

Should correspond to

jobject Java_my_package_NativeAlloc(JNIEnv* env, jclass someClass, jint numBytes)

By omitting the jclass argument you risk corrupting the other arguments.

This may have balanced out the jint/jlong mistake in your code on some platforms, but not on others.

Answer 2

Not really an answer, but... Your app is Requiring 1228800bytes and -5457750921690562560 is a 64-bit number, whose lower part is 1228800 (0x12C000) and the higher part is 0xB4422C74. Probably a 64-bit fetch is done from an address containing a 32-bit number (the length). If you could place 0 after the length, this would probably solve the problem. But you have to locate the place.

Does the bug happen on a 64-bit desktop system? If so, you could try a 32-bit version.