I have a native executable that crash on start on x86_64 (API30) but runs fine on x86. Also runs fine on X86_64 API 21.
The first line of code in its entry point is:
printf("Starting");
Also tested this:
__android_log_print(ANDROID_LOG_WARN, TAG, "Starting");
Here is the dump when using log_print:
signal 11 (SIGSEGV), code 128 (SI_KERNEL), fault addr 0x0
#00 pc 0000000000009a24 /system/lib64/liblog.so (__android_log_level(char const*, unsigned long)+132) (BuildId: fe04dbc8d214fc65da81cacaf867b284)
#01 pc 0000000000009ec7 /system/lib64/liblog.so (__android_log_is_loggable+55) (BuildId: fe04dbc8d214fc65da81cacaf867b284)
#02 pc 0000000000007a27 /system/lib64/liblog.so (__android_log_print+135) (BuildId: fe04dbc8d214fc65da81cacaf867b284)
#03 pc 000000000009ca74 /data/app/~~XDpzR94g1TpiMQSCYqgNvA==/ccc71.at.free-SQEF9Jt3nPM0qDRUmW3P1Q==/lib/x86_64/liblib3c.so (entry_point+36) (BuildId: 6fa63521ac2c4be916d2aad9640a192de6db6ef3)
#04 pc 0000000000000001 <unknown>
Here is the dump when using printf():
backtrace:
#00 pc 00000000000c1cd0 /apex/com.android.runtime/lib64/bionic/libc.so (printf+112) (BuildId: 3707c39fc397eeaa328142d90b50a973)
#01 pc 000000000009ca88 /data/app/~~b68Ahj-zb4or4ECmKeyAhQ==/ccc71.at.free-v45ABuNSbmqW6dkOBadBZw==/lib/x86_64/liblib3c.so (entry_point+24) (BuildId: b80461f2139db953674f6a3eb7a0eefbe02b891e)
#02 pc 0000000000000001 <unknown>
The only particular setting I'm using at build time are this:
-DCMAKE_SHARED_LINKER_FLAGS=-shared -fPIC -Wl,-e,entry_point -Wl,--gc-sections
This allows the exe to be loaded as a library from the Java app and run as executable from shell. It works perfectly on arm 32/64 bits devices.
Any help in solving this would be appreciated.
Related
My unity game is crashing on few android devices. Below is the crashlytics log:
Crashed: Thread: SIGSEGV 0x0000007b60251000
#00 pc 0x4d3fc libc.so
#01 pc 0x39fcffc libil2cpp.so
#02 pc 0xb30d4c libil2cpp.so
#03 pc 0x39fd6fc libil2cpp.so
#04 pc 0xb124dc libil2cpp.so
#05 pc 0xb12524 libil2cpp.so
#06 pc 0xb124dc libil2cpp.so
#07 pc 0xb2ae20 libil2cpp.so
#08 pc 0xc7ffc libc.so
#09 pc 0xb87f44 libil2cpp.so
#10 pc 0xb6c6c libc.so
#11 pc 0x5329c libc.so
#12 pc 0xb6b30 libc.so
#13 pc 0xb2a6d0 libil2cpp.so
#14 pc 0xb87f24 libil2cpp.so
I am struggling with it from a long time. It is also affecting my game's rating on play store. If anyone know about it, please help me. Thanks.
Lately, we're experiencing native crashes spike in production. All those crashes are related to rendering UI and happened mostly on Android 12 and vendors like Samsung. Some of them from Play Console are:
[libhwui.so] SkCanvas::restore()
SIGSEGV
backtrace:
#00 pc 0x000000000026c9d8 /system/lib64/libhwui.so (SkCanvas::restore()+344)
#01 pc 0x000000000026c73c /system/lib64/libhwui.so
(android::SkiaCanvas::restore()+52)
#02 pc 0x00000000002008e0 /system/lib64/libhwui.so
(android::CanvasJNI::restore(long)+56)
#03 pc 0x0000000000bef14c /data/misc/apexdata/com.android.art/dalvik-
cache/arm64/boot.oat (android.graphics.Canvas.restore+60)
or
[[vdso]] __kernel_rt_sigreturn
SIGSEGV
#00 pc 0x00000000001ac258 /apex/com.android.art/lib64/libart.so
(art::ArtMethod::GetOatQuickMethodHeader(unsigned long)+40)
#01 pc 0x0000000000597864 /apex/com.android.art/lib64/libart.so (void
art::StackVisitor::WalkStack<(art::StackVisitor::CountTransitions)0>(bool)+516)
#02 pc 0x000000000059a514 /apex/com.android.art/lib64/libart.so
(art::StackVisitor::GetVRegFromDebuggerShadowFrame(unsigned short, art::VRegKind,
unsigned int*) const+284)
#03 pc 0x000000000059a314 /apex/com.android.art/lib64/libart.so
(art::StackVisitor::GetVReg(art::ArtMethod*, unsigned short, art::VRegKind, unsigned
int*, std::__1::optional<art::DexRegisterLocation>) const+76)
But we cannot understand their cause because neither Firebase Crashlytics nor other third parties can catch native crashes. We've googled everything and found nothing about how to get more data for the native crashes to find the cause. Maybe somebody has an experience with it and can share.
Note: Symbols are showing up in crashlytics for our c++ library, the problem is that they aren't showing for system libraries like libc, libart, libbase, and libandroid_runtime.
We have some tricky crashes that happen entirely in the Android runtime and these are hard to debug without symbols. In firebase crashlytics we see the following stack trace:
Crashed: Thread : SIGABRT 0x0000000000000000
#00 pc 0x4e574 libc.so
#01 pc 0x4e540 libc.so
#02 pc 0x5677d8 libart.so
#03 pc 0x13ab0 libbase.so
#04 pc 0x13090 libbase.so
#05 pc 0x38cb6c libart.so
#06 pc 0x39f7d8 libart.so
#07 pc 0x1260e0 libandroid_runtime.so
#08 pc 0x124ef4 libandroid_runtime.so
#09 pc 0x124dc4 libandroid_runtime.so
#10 pc 0x115468 libandroid_runtime.so
When I force a test crash in our C++ library by dereferencing a null pointer, I see the following backtrace in my local Android Studio console:
...snip...
#06 pc 00000000002d7644 /apex/com.android.art/lib64/libart.so (art_quick_generic_jni_trampoline+148) (BuildId: adb75d6f792faa24b1bc8cf512fb112c)
#07 pc 00000000002cdd64 /apex/com.android.art/lib64/libart.so (art_quick_invoke_stub+548) (BuildId: adb75d6f792faa24b1bc8cf512fb112c)
#08 pc 00000000002f23d0 /apex/com.android.art/lib64/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+312) (BuildId: adb75d6f792faa24b1bc8cf512fb112c)
#09 pc 00000000003839f4 /apex/com.android.art/lib64/libart.so (bool art::interpreter::DoCall<true, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+800) (BuildId: adb75d6f792faa24b1bc8cf512fb112c)
#10 pc 00000000003813f4 /apex/com.android.art/lib64/libart.so (MterpInvokeVirtualRange+1368) (BuildId: adb75d6f792faa24b1bc8cf512fb112c)
#11 pc 00000000002c8714 /apex/com.android.art/lib64/libart.so (mterp_op_invoke_virtual_range+20) (BuildId: adb75d6f792faa24b1bc8cf512fb112c)
...snip...
However, the same crash in crashlytics looks like this:
...snip...
#07 pc 0x222244 libart.so
#08 pc 0x218964 libart.so
#09 pc 0x284208 libart.so
#10 pc 0x3e34ac libart.so
#11 pc 0x800ba4 libart.so
...snip...
How can we get crashlytics to include the information that is clearly in the crashdump?
Some notes on our build setup:
We have already followed https://firebase.google.com/docs/crashlytics/ndk-reports
Gradle Project 1 builds the native library, ensuring that debug is on and symbols are not stripped.
Gradle Project 2 builds the app and links in the library and tells crashlytics to upload native symbols
firebaseCrashlytics {
nativeSymbolUploadEnabled true
unstrippedNativeLibsDir file("PATH/TO/UNSTRIPPED/DIRECTORY")
}
This behavior is expected. When Crashlytics gets NDK crashes, these need to be symbolicated. In order to do this, the respective symbol files should be uploaded to Crashlytics.
With the configuration you mentioned, the symbols available in your app will be uploaded to Crashlytics.
nativeSymbolUploadEnabled true
But in the case of system libraries, the respective symbol files are not available (they are not public as far as I know). So Crashlytics won't have access to the required symbol files for symbolicating frames from system libraries.
My Android app is suffering from an'abort' error after recent update.
But I don't know why this problem happens and how can I debug it.
This 'abort' error occurred especially on Android 10 and 11.
It is not recorded on Firebase Crashlytics, I can see it only on Google play console.
The log is as below.
backtrace:
#00 pc 000000000004ef24 /apex/com.android.runtime/lib64/bionic/libc.so (abort+164)
#00 pc 000000000053b078 /apex/com.android.art/lib64/libart.so (art::Runtime::Abort(char const*)+2340)
#00 pc 000000000001394c /system/lib64/libbase.so (android::base::SetAborter(std::__1::function<void (char const*)>&&)::$_3::__invoke(char const*)+76)
#00 pc 00000000000130cc /system/lib64/libbase.so (android::base::LogMessage::~LogMessage()+312)
#00 pc 000000000058e1d4 /apex/com.android.art/lib64/libart.so (art::Thread::AssertNoPendingException() const+1836)
#00 pc 00000000001c15cc /apex/com.android.art/lib64/libart.so (art::ClassLinker::FindClass(art::Thread*, char const*, art::Handle<art::mirror::ClassLoader>)+64)
#00 pc 0000000000380c34 /apex/com.android.art/lib64/libart.so (art::JNI<false>::FindClass(_JNIEnv*, char const*)+1144)
#00 pc 00000000000200d4 /data/app/~~0HXm4UzxwERXczUAACEC9g==/com.****.****-L0QwKgab-Tg3REmBFsu7iA==/lib/arm64/libmm.so
#00 pc 0000000000020b90 /data/app/~~0HXm4UzxwERXczUAACEC9g==/com.****.****-L0QwKgab-Tg3REmBFsu7iA==/lib/arm64/libmm.so
#00 pc 00000000000b6234 /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+64)
#00 pc 0000000000050e64 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)
I applied 'View Binding' to this update.
Could it be an cause?
Also I wonder if an Android app can be alive when 'abort' error occurred.
Please help me...
libmm is a file of an obfuscation solution which we applied to the app. It is a binary obfuscation solution and it is run before application runs on memory as far as I know.
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?
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:
Check if _BSD_SOURCE is defined.
Did you upgrade the NDK?
Did you change minSdkVersion?
Did you change from gcc to Clang?
My solution to this crash was to avoid funopen entirely.