Cosa potrebbe causare SIGSEGV quando si chiama NewObjectArray per JNI in Android?

Question

Ho appena iniziato a lavorare con Android NDK ma continuo a ricevere SIGSEGV quando ho questa chiamata nel mio codice C:

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

Basandomi su tutti gli esempi che riesco a trovare, il codice sopra è corretto ma continuo a ricevere SIGSERGV e tutto va bene se la riga NewObjectArray è commentata.Qualche idea su cosa potrebbe causare un simile problema?

Answer 1

che guarda a destra, quindi sto cercando di indovinare che hai fatto qualcosa che non va. Suppongo si sta eseguendo con checkjni su? si potrebbe desiderare di rompere che fino in più righe:. fare il FindClass e controllare il valore di ritorno, fare il NewStringUTF e controllare il valore di ritorno, e quindi chiamare NewObjectArray

A proposito, si potrebbe desiderare di passare NULL come argomento finale; questo modello di utilizzare la stringa vuota come valore di default per ogni elemento dell'array è comunemente usato (i che sia copia e incollato da qualche documentazione Sun e si è diffuso da lì) ma è raramente utile, ed è leggermente spreco. (E non corrisponde il comportamento di "new String [10]" in Java.)

Answer 2

Immagino che una delle possibili cause sia che in un metodo JNI a lungo termine, la VM si interrompe quando si esauriscono gli slot di riferimento locale per invocazione del metodo (normalmente 512 slot in Android).

Poiché le funzioni FindClass() e NewStringUTF() allocherebbero riferimenti locali, se si rimane in un metodo JNI per un lungo periodo, la VM non saprà se un riferimento locale specifico debba essere riciclato o meno.Quindi dovresti chiamare esplicitamente DeleteLocalRef() per rilasciare i riferimenti locali acquisiti quando non sono più necessari.Se non lo fai, i riferimenti locali "zombie" occuperanno gli slot nella VM e la VM si interromperà mentre esauriscono tutti gli slot di riferimento locale.

Nel metodo JNI a breve termine, questo potrebbe non costituire un problema poiché tutti i riferimenti locali verrebbero riciclati all'uscita da un metodo JNI.