JNI Uncaught исключение типа <unknown>... как это происходит? - PullRequest
5 голосов
/ 20 августа 2011

У меня есть некоторый код Java, который вызывает код C ++, и код C ++ поворачивается и вызывает Java, все через JNI.Мы получали пресловутый «hs_err_pidXXXX.log», который, как ни странно, происходил, когда мы вызывали JNIEnv_::GetMethodID(myJniEnv->GetObjectClass(anException), "printStackTrace", "()V") для ожидающего исключения в настоящий момент!Поэтому мы добавили:

if ((javaException = getJniEnv()->ExceptionOccurred()) != NULL)
{
   jniEnv->ExceptionDescribe();
   .... <other exception handling code> ...
}

... после каждого раза, когда мы вызываем JNI, чтобы попытаться выяснить, что произошло исключение.Результат ExceptionDescribe () был:

Uncaught exception of type <unknown>

Как это происходит?Приведенное выше значение anException пришло прямо из вызова JNI к anException = myJniEnv->ExceptionOccurred(), что должно дать бросок, верно?Я должен был бы быть в состоянии напечатать трассировку стека на throwable без сбоя JNI, я бы подумал.Кто-нибудь когда-нибудь сталкивался с чем-то подобным?

1 Ответ

7 голосов
/ 26 августа 2011

Это звучит как проблема повреждения памяти, возможно, из-за локальных ссылок Java, которые уже были очищены. Попробуйте добавить некоторые или все следующие параметры в командную строку Java (или аргументы создания JVM в C / C ++):

  -verbose:jni
  -verbose:gc
  -Xcheck:jni

Вероятно, наиболее интересным из них является –Xcheck: jni (см. Документы командной строки). Это добавит кучу проверок для таких вещей, как использование уже удаленных локальных ссылок, и выдаст исключение в момент обнаружения ошибки, а не намного дальше в вашей программе, когда память уже повреждена. Как только вы получите исключение Java в исходном источнике ошибки, должно быть намного проще использовать отладчик (например, GDB для поиска места сбоя C ++) или трассировку стека Java, чтобы точно определить, где происходит ошибка, и, надеюсь, точно определить точное объект, вызывающий проблему.

Я узнал об этом от нашего постоянного воина JNI на работе;)

...