r17b - jni android studio

¿Qué podría causar SIGSEGV al llamar a NewObjectArray para JNI en Android?

Question

Empecé a trabajar con Android NDK pero sigo recibiendo SIGSEGV cuando recibo esta llamada en mi código C:

jobjectArray someStringArray;
someStringArray = (*env)->NewObjectArray(env, 10,
(*env)->FindClass(env,"java/lang/String"),(*env)->NewStringUTF(env, ""));

Basado en todo el ejemplo que puedo encontrar, el código anterior es correcto, pero sigo obteniendo SIGSERGV y todo está bien si la línea NewObjectArray está comentada. ¿Alguna idea de lo que podría causar tal problema?

Answer 1

eso se ve bien, así que supongo que has hecho algo diferente. Supongo que estás corriendo con checkjni en? Es posible que desee dividirlo en varias líneas: haga FindClass y verifique el valor de retorno, haga NewStringUTF y verifique el valor de retorno, y luego llame a NewObjectArray.

por cierto, es posible que desee pasar NULL como argumento final; este patrón de uso de la cadena vacía ya que el valor predeterminado para cada elemento de la matriz se usa comúnmente (creo que es copiar y pegar de alguna documentación de Sun y se ha extendido desde allí) pero rara vez es útil, y es un poco derrochador. (y no coincide con el comportamiento de "new String [10]" en Java).

Answer 2

Supongo que una de las posibles causas es que en un método JNI de larga ejecución, la máquina virtual se anula al quedarse sin las ranuras de referencia locales de invocación por método (normalmente 512 espacios en Android).

Como las funciones FindClass () y NewStringUTF () asignarían referencias locales, si permaneces en un método JNI durante mucho tiempo, la VM no sabe si se debe reciclar una referencia local específica o no. Por lo tanto, debe llamar explícitamente a DeleteLocalRef () para liberar las referencias locales adquiridas cuando ya no sean necesarias. Si no hace esto, las referencias locales "zombis" ocuparán ranuras en la VM, y la máquina virtual abortará mientras se quedan sin todas las ranuras de referencia locales.

En el método JNI de corto plazo, esto puede no ser un problema debido a que todas las referencias locales se reciclarían al salir de un método JNI.