Что может вызвать SIGSEGV при вызове NewObjectArray для JNI в Android?

Я только начал работать с Android NDK, но я продолжаю получать SIGSEGV, когда у меня есть этот вызов в моем коде C:

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

Основываясь на всех примерах, которые я могу найти, приведенный выше код правильный, но я продолжаю получать SIGSERGV, и все в порядке, если строка NewObjectArray закомментирована. Любая идея, что может вызвать такую ​​​​проблему?


android-ndk java-native-interface
person Ken    schedule 21.01.2010    source источник
comment
Забыл упомянуть, я использую NDK1.6   -  person Ken    schedule 22.01.2010

Ответы (2)


arrow_upward
5
arrow_downward

это выглядит правильно, поэтому я предполагаю, что вы сделали что-то еще не так. Я предполагаю, что вы работаете с включенным checkjni? вы можете разбить это на несколько строк: выполните FindClass и проверьте возвращаемое значение, выполните NewStringUTF и проверьте возвращаемое значение, а затем вызовите NewObjectArray.

Кстати, вы можете передать NULL в качестве последнего аргумента; этот шаблон использования пустой строки в качестве значения по умолчанию для каждого элемента массива обычно используется (я думаю, что он скопирован и вставлен из какой-то документации Sun и оттуда распространился), но он редко полезен и немного расточительный. (и это не соответствует поведению «новой строки [10]» в Java.)

person Elliott Hughes    schedule 23.01.2010

arrow_upward
2
arrow_downward

Я предполагаю, что одна из возможных причин заключается в том, что в долгосрочном методе JNI виртуальная машина прерывается при исчерпании локальных эталонных слотов для вызова метода (обычно 512 слотов в Android).

Поскольку функции FindClass() и NewStringUTF() будут выделять локальные ссылки, если вы остаетесь в методе JNI в течение длительного времени, виртуальная машина не знает, следует ли повторно использовать конкретную локальную ссылку или нет. Таким образом, вы должны явно вызвать DeleteLocalRef(), чтобы освободить полученные локальные ссылки, когда они больше не нужны. Если вы этого не сделаете, локальные ссылки «зомби» займут слоты в виртуальной машине, и виртуальная машина прекратит работу, когда все слоты локальных ссылок будут исчерпаны.

В краткосрочном методе JNI это может не быть проблемой, поскольку все локальные ссылки будут повторно использоваться при выходе из метода JNI.

person Joseph Tsai    schedule 12.08.2011