Reputation: 11
Our App does not contain any c/c++ code, while we use some third part sdk who contains .so
Now, we found a big percent native crash?
we can not find useful info to get which sdk to bear the responsibility. And the crash point to , like "libc.so", "libart.so" and "/system/framework/arm/boot-framework.oat"
So, what can i do to solve the crashs? to upgrade sdk? but I dont known which to upgrade
I can not get any info of our app...
==========================================
Process Name: 'com.xxxxxxxxxxx'
Thread Name: 'RenderThread'
pid: 23247, tid: 13872 >>> com.xxxx <<<
signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
r0 00000000 r1 00003630 r2 00000006 r3 b71adb30
r4 b71adb44 r5 b71adb28 r6 00005acf r7 0000016b
r8 b71adb40 r9 b71adb30 10 b71adb60 fp b71adb50
ip 00003630 sp b71adb00 lr e6ed9deb pc e6ed9dfe cpsr
008f0030
d0 696c657069504c47 d1 6e65704f61696b53
d2 7577682f7362696c d3 696c657069702f69
d4 0000000000000000 d5 0000000000000000
d6 0000000000000000 d7 0000000000000000
d8 0000000000000000 d9 0000000000000000
d10 0000000000000000 d11 0000000000000000
d12 0000000000000000 d13 0000000000000000
d14 0000000000000000 d15 0000000000000000
d16 ffffffffffffffff d17 2e6761742e676f6c
d18 e6eb8769e6eb8761 d19 e6eb8775e6eb8771
d20 0000000000000000 d21 0000000000000000
d22 0000000000fffdd6 d23 0000000000ffff5a
d24 0000000000ffffeb d25 0000000001000000
d26 0000000000000000 d27 000000000000001d
d28 0000000000000000 d29 000000001d000000
d30 00d600d600d600d6 d31 0000000000000000
scr 28000093
#00 pc 0002ddfe /apex/com.android.runtime/lib/bionic/libc.so (abort)
#00 pc 0002ddfe /apex/com.android.runtime/lib/bionic/libc.so
#01 pc 0002ddeb /apex/com.android.runtime/lib/bionic/libc.so
--- --- ---
[DEBUG] Read self maps instead! map: 0x0
00 pc 0002ddfe /apex/com.android.runtime/lib/bionic/libc.so
(abort+165)
01 pc 00001aad liblog.so (__android_log_assert+176)
02 pc 00124ff7 libhwui.so
03 pc 00122bdd libhwui.so
04 pc 00122131 libhwui.so
05 pc 001308b9 libhwui.so
06 pc 0013070b libhwui.so
07 pc 000039af libutils.so
(_ZN7android6Thread11_threadLoopEPv+210)
08 pc 0007a22d /apex/com.android.runtime/lib/bionic/libc.so
(_ZL15__pthread_startPv+20)
09 pc 0002f2a9 /apex/com.android.runtime/lib/bionic/libc.so
(__start_thread+30)
--- --- ---
--- --- --- ---
memory near r1:
00003630 -------- -------- -------- -------- ................
memory near r3:
b71adaf0 e662537d b71adb28 00005acf 0000007e }Sb.(....Z..~...
b71adb00 b71adb70 b71adb80 b71adb90 b71adba0 p...............
b71adb10 a6363000 8e60f3d2 00021d02 a8b02323 .06...`.....##..
b71adb20 0000000f 00000003 ffffffdf ffffffff ................
b71adb30 00000000 00000000 ffffffff 00005acf .............Z..
b71adb40 00002735 00000000 00000000 00000000 5'..............
b71adb50 00000000 00000000 00000000 00000000 ................
b71adb60 00000000 00000000 00000000 00000000 ................
b71adb70 00000000 00000000 00000000 00000000 ................
b71adb80 00000000 00000000 00000000 00000000 ................
b71adb90 00000000 00000000 00000000 00000000 ................
b71adba0 00000000 00000000 00000000 00000000 ................
b71adbb0 00000000 00000000 00000000 00000000 ................
b71adbc0 b71adbf8 e662537d e918f0b2 d722ad50 ....}Sb.....P.".
b71adbd0 0000007e b71ae060 ffffffff b71ae060 ~...`.......`...
b71adbe0 9434e1bc e9191ab1 e6608a45 b71ae00c ..4.....E.`.....
Upvotes: 1
Views: 16637
Reputation: 1
I also encountered the same problem recently.
There is a high probability of a crash, not only for the "RenderThread" thread, but also for the "FinalizerDaemon" thread, "HeapTaskDaemon" thread, main thread, or JNI callback thread.
I tested the code bit by bit and finally discovered the reason why my code caused a high probability of crashing.
The reason for this issue is that my JNI dynamic library is compiled from multiple CPP source code files, and I have defined the same structure alias and the same static global unique_ptr variable in different CPPs.
A.cpp and B.cpp both have the following code:
using CallbackObjInfo = struct {
……
};
static std::unique_ptr<CallbackObjInfo> g_callback;
static jboolean InitCallback(JNIEnv *env, jobject stateCallback) {
……
std::unique_ptr<CallbackObjInfo> callback = std::make_unique<CallbackObjInfo>();
……
g_callback= std::move(callback);
}
Finally, defining different structural aliases and global static variable names in A.cpp and B.cpp respectively solved this problem.
I hope my experience can be helpful to you.
Upvotes: 0
Reputation: 1360
Fixing native crashes from external SDKs is always hard. One try would be to check the whole stack trace you get when the crash occurs. There might be just hex addresses on the very top, but somewhere deeper down there might be some lines of code, which might actually help you. See for example this crash we had in our app:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> one.realnote.app <<<
backtrace:
#00 pc 0000000000fc40d4 /data/app/com.google.ar.core-SbkhfyZZQu51a6XNR_3aGQ==/base.apk!libarcore_c.so (offset 0x6e0000)
#00 pc 0000000000fc358c /data/app/com.google.ar.core-SbkhfyZZQu51a6XNR_3aGQ==/base.apk!libarcore_c.so (offset 0x6e0000)
#00 pc 0000000000fc29ec /data/app/com.google.ar.core-SbkhfyZZQu51a6XNR_3aGQ==/base.apk!libarcore_c.so (offset 0x6e0000)
#00 pc 0000000000fc2478 /data/app/com.google.ar.core-SbkhfyZZQu51a6XNR_3aGQ==/base.apk!libarcore_c.so (offset 0x6e0000)
#00 pc 0000000001951958 /data/app/com.google.ar.core-SbkhfyZZQu51a6XNR_3aGQ==/base.apk!libarcore_c.so (offset 0x6e0000)
#00 pc 000000000193eb2c /data/app/com.google.ar.core-SbkhfyZZQu51a6XNR_3aGQ==/base.apk!libarcore_c.so (offset 0x6e0000) (ArSession_update+152)
#00 pc 000000000000eb8c /data/app/one.realnote.app-g6hR_qK9swLsb5Br8mzp-Q==/base.apk!lib/arm64-v8a/libarcore_sdk_jni.so (offset 0x6a1000) (Java_com_google_ar_core_Session_nativeUpdate+48)
#00 pc 0000000000076cfc /data/app/one.realnote.app-g6hR_qK9swLsb5Br8mzp-Q==/oat/arm64/base.odex (art_jni_trampoline+140)
#00 pc 00000000020c90c0 /memfd:/jit-cache (com.google.ar.sceneform.ArSceneView.onBeginFrame+368)
#00 pc 00000000020d1274 /memfd:/jit-cache (com.google.ar.sceneform.SceneView.doFrameNoRepost+164)
#00 pc 00000000020c259c /memfd:/jit-cache (com.google.ar.sceneform.SceneView.doFrame+172)
#00 pc 0000000000a2bed4 /system/framework/arm64/boot-framework.oat (android.view.Choreographer.doCallbacks+692)
#00 pc 0000000000a2c668 /system/framework/arm64/boot-framework.oat (android.view.Choreographer.doFrame+1224)
#00 pc 0000000000b07038 /system/framework/arm64/boot-framework.oat (android.view.Choreographer$FrameDisplayEventReceiver.run+72)
#00 pc 00000000007eeadc /system/framework/arm64/boot-framework.oat (android.os.Handler.dispatchMessage+76)
#00 pc 00000000007f21b8 /system/framework/arm64/boot-framework.oat (android.os.Looper.loop+1448)
#00 pc 0000000000552294 /system/framework/arm64/boot-framework.oat (android.app.ActivityThread.main+772)
#00 pc 00000000001375b8 /apex/com.android.runtime/lib64/libart.so (art_quick_invoke_static_stub+568)
#00 pc 00000000001460cc /apex/com.android.runtime/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+276)
#00 pc 00000000004b24b8 /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::InvokeWithArgArray(art::ScopedObjectAccessAlreadyRunnable const&, art::ArtMethod*, art::(anonymous namespace)::ArgArray*, art::JValue*, char const*)+104)
#00 pc 00000000004b3f00 /apex/com.android.runtime/lib64/libart.so (art::InvokeMethod(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jobject*, _jobject*, unsigned long)+1472)
#00 pc 000000000043f658 /apex/com.android.runtime/lib64/libart.so (art::Method_invoke(_JNIEnv*, _jobject*, _jobject*, _jobjectArray*)+48)
#00 pc 00000000000c8c34 /system/framework/arm64/boot.oat (art_jni_trampoline+180)
#00 pc 0000000000aaa8f8 /system/framework/arm64/boot-framework.oat (com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run+136)
#00 pc 0000000000ab3044 /system/framework/arm64/boot-framework.oat (com.android.internal.os.ZygoteInit.main+3012)
#00 pc 00000000001375b8 /apex/com.android.runtime/lib64/libart.so (art_quick_invoke_static_stub+568)
#00 pc 00000000001460cc /apex/com.android.runtime/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+276)
#00 pc 00000000004b24b8 /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::InvokeWithArgArray(art::ScopedObjectAccessAlreadyRunnable const&, art::ArtMethod*, art::(anonymous namespace)::ArgArray*, art::JValue*, char const*)+104)
#00 pc 00000000004b2118 /apex/com.android.runtime/lib64/libart.so (art::InvokeWithVarArgs(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, std::__va_list)+408)
#00 pc 00000000003bc968 /apex/com.android.runtime/lib64/libart.so (art::JNI::CallStaticVoidMethodV(_JNIEnv*, _jclass*, _jmethodID*, std::__va_list)+624)
#00 pc 00000000000eeafc /system/lib64/libandroid_runtime.so (_JNIEnv::CallStaticVoidMethod(_jclass*, _jmethodID*, ...)+116)
#00 pc 00000000000f1c1c /system/lib64/libandroid_runtime.so (android::AndroidRuntime::start(char const*, android::Vector<android::String8> const&, bool)+804)
#00 pc 00000000000034f0 /system/bin/app_process64 (main+1184)
#00 pc 000000000007e86c /apex/com.android.runtime/lib64/bionic/libc.so (__libc_init+108)
Some hex counters but somewhere inside you can see calls like com.google.ar.sceneform.SceneView.doFrameNoRepost+164
, which gives you the crashing SDK (ARCore for us) but also the area of where it crashes. this way you can check in your code, where you have contact points with that specific SDK behavior, and check for possible errors on your side. If you are not already doing so, I recommend using Firebase Crashlytics with native support to get your stack traces in an online console.
Upvotes: 0