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

Question

acaba de empezar a trabajar con el NDK de Android, pero me siguen dando SIGSEGV cuando tengo esta llamada en mi código C:

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

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

Answer 1

que 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 usar la cadena vacía como el valor predeterminado para cada elemento de la matriz se usa comúnmente (creo que es una copia & pegada 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 aborta cuando se queda sin ranuras de referencia locales de invocación por método (normalmente 512 ranuras en Android).

Dado que las funciones FindClass() y NewStringUTF() asignarían referencias locales, si permanece en un método JNI durante mucho tiempo, la VM no sabe si una referencia local específica debe reciclarse 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 tirada corta, esto puede no ser un problema debido a que todas las referencias locales se reciclarían al salir de un método JNI.