Ce qui pourrait provoquer SIGSEGV lors de l'appel NewObjectArray pour JNI dans Android?

Question

Je viens de commencer à travailler avec le NDK Android, mais je continue à me SIGSEGV quand j'ai cet appel dans mon code C:

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

Base sur tout l'exemple que je peux trouver, le code ci-dessus est correct, mais je continue à me SIGSERGV et tout est ok si la ligne NewObjectArray est commenté. Toute idée de ce qui pourrait causer un tel problème?

Answer 1

qui regarde à droite, donc je suppose que vous avez fait quelque chose d'autre mal. Je suppose que vous êtes en cours d'exécution avec checkjni sur? vous pourriez vouloir briser cette place en plusieurs lignes. faire la FindClass et vérifier la valeur de retour, procédez NewStringUTF et vérifier la valeur de retour, puis appelez NewObjectArray

BTW, vous pouvez passer NULL comme argument final; ce modèle d'utiliser la chaîne vide comme valeur par défaut pour chaque élément du tableau est couramment utilisé (je pense qu'il est copier et coller à partir de la documentation Sun et la propagation de là), mais il est rarement utile, et il est un peu inutile. (Et il ne correspond pas au comportement de "new String [10]" en Java.)

Answer 2

Je suppose que l'une des causes possibles est que, dans un procédé JNI à long terme, la machine virtuelle est abandonnée lors de l'exécution des fentes de référence locaux par méthode invocation (normalement 512 machines à sous dans les applications).

Depuis FindClass () et NewStringUTF () consacreraient références locales, si vous restez dans une méthode JNI pendant longtemps, la machine virtuelle ne sais pas si doit être recyclé ou non une référence locale spécifique. Donc, vous devez appeler explicitement DeleteLocalRef () pour libérer les références locales acquises lorsqu'ils ne sont pas nécessaires plus. Si vous ne le faites pas, les références locales « zombies » occuperont des fentes dans VM, et la machine virtuelle avorte lors de l'exécution de toutes les fentes de référence locales.

Dans la méthode JNI à court terme, cela peut ne pas être un problème en raison de toutes les références locales seraient recyclés lors de la sortie d'une méthode JNI.