多くの StackOverflow の質問に対するコメントは、deadd00d の障害アドレスが意図的な VM の中止を示していることを指摘しています。
I DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadd00d
実際、ndk-stack を介してログを実行すると、スタック フレームの上部が次のようにデコードされることがわかります。
Stack frame #00 pc 00050b0e /system/lib/libdvm.so (dvmAbort)
次に、コメントは、ログの前の方で問題を探すように言っています。正確には何を探していますか? 検索する特定のタグまたは文字列はありますか? (おそらく dalvikvm?) ログの多くのページをスクロールしましたが、関連するものは何も見つかりませんでした。それは正常ですか、それとも障害の直前ですか?
Deadd00d は、GetObjectClass() への特定の呼び出し内で最も頻繁に発生します。その行の直前に env->ExceptionCheck を呼び出してみましたが、以前のエラーは報告されません。
また、CheckJNIをオンにしてみました
adb shell setprop debug.checkjni 1
こちらとこちらの手順に従ってください。ただし、アプリを強制終了して再起動すると、予期したメッセージが表示されません
D Late-enabling CheckJNI
むしろ
D AndroidRuntime: CheckJNI is OFF
Usingadb shell getpropは、プロパティが実際にオンになっていることを示しているため、そこで何が起こっているのかわかりません。