Reputation: 31
I am working on the migration of the 32bit NDK project to 64bit. We are calling so many libs in projects: like - libssl.so, libcrypto.so, libc.so, liblog.so, libcrashlytics.so
In project going to read kernel process by fopen but somehow, I am getting FATAL signal error and Android logcat showing as below
A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xafef03c4 in tid 12462 (eradocs.android), pid 12462 (eradocs.android)
======================== Below Crash dump found on stack-trace
#00 0x00000000afef03c4 - This memory address is matching with above fatal signal error.
#06 0x000000000013f350 /apex/com.android.runtime/lib64/libart.so (art_quick_generic_jni_trampoline+144) (BuildId: d700c52998d7d76cb39e2001d670e654)
#07 0x00000000001365b8 /apex/com.android.runtime/lib64/libart.so (art_quick_invoke_static_stub+568) (BuildId: d700c52998d7d76cb39e2001d670e654)
#08 0x000000000014500c /apex/com.android.runtime/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+276) (BuildId: d700c52998d7d76cb39e2001d670e654)
#09 0x00000000002e2928 /apex/com.android.runtime/lib64/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+384) (BuildId: d700c52998d7d76cb39e2001d670e654)
#10 0x00000000002ddb88 /apex/com.android.runtime/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+892) (BuildId: d700c52998d7d76cb39e2001d670e654)
#11 0x00000000005a28ac /apex/com.android.runtime/lib64/libart.so (MterpInvokeStatic+372) (BuildId: d700c52998d7d76cb39e2001d670e654)
#12 0x0000000000130994 /apex/com.android.runtime/lib64/libart.so (mterp_op_invoke_static+20) (BuildId: d700c52998d7d76cb39e2001d670e654)
#14 0x00000000002b3c3c /apex/com.android.runtime/lib64/libart.so
Can anyone help me with this stacktrace? Is there a way to find the root cause of this?
Upvotes: 1
Views: 1518
Reputation: 19937
I bet one of your libraries makes use of the funopen
trick to be able to read assets from native code. That trick used to work, but as both Android and the NDK evolved, the hack soon became more or less obsolete. I used it until I upgraded the NDK and got a similar crash.
See NDK issue #562 and this old blog post. Both mention this SIGSEGV
error.
Some quick pointers include:
_BSD_SOURCE
is defined.minSdkVersion
?gcc
to Clang
?My solution to this crash was to avoid funopen
entirely.
Upvotes: 1