Току-що започнах да работя с Android NDK, но продължавам да получавам SIGSEGV, когато имам това извикване в моя C код:
jobjectArray someStringArray;
someStringArray = (*env)->NewObjectArray(env, 10,
(*env)->FindClass(env,"java/lang/String"),(*env)->NewStringUTF(env, ""));
Въз основа на всички примери, които мога да намеря, горният код е правилен, но продължавам да получавам SIGSERGV и всичко е наред, ако редът NewObjectArray е коментиран. Някаква идея какво може да причини такъв проблем?
това изглежда правилно, така че предполагам, че сте направили нещо друго грешно. предполагам, че работите с включен checkjni? може да искате да го разделите на няколко реда: направете FindClass и проверете върнатата стойност, направете NewStringUTF и проверете върнатата стойност и след това извикайте NewObjectArray.
между другото, може да искате да подадете NULL като последен аргумент; този модел на използване на празния низ като стойност по подразбиране за всеки елемент от масива се използва често (мисля, че е копиран и поставен от някаква документация на Sun и се е разпространил от там), но рядко е полезен и е леко разточителен. (и не съвпада с поведението на „нов низ [10]“ в Java.)
Предполагам, че една от възможните причини е, че в дългосрочен JNI метод, VM прекъсва, когато изчерпват локалните референтни слота за извикване на метод (обикновено 512 слота в Android).
Тъй като функциите FindClass() и NewStringUTF() биха разпределили локални препратки, ако останете в JNI метод за дълго време, VM не знае дали конкретна локална препратка трябва да бъде рециклирана или не. Така че трябва изрично да извикате DeleteLocalRef(), за да освободите придобитите локални препратки, когато вече не са необходими. Ако не направите това, „зомби“ локалните препратки ще заемат слотове във VM и VM прекратява, докато изчерпва всички локални референтни слотове.
При краткосрочен JNI метод това може да не е проблем, тъй като всички локални препратки ще бъдат рециклирани при излизане от JNI метод.
