如何象征libart.so或libc.So so stackTraces android ndk中的stacktraces？

发布于 2025-02-09 12:50:55 字数 2799 浏览 2 评论 0 原文

注意：符号在我们的C ++库中显示在crashlytics中，问题是它们没有显示 libc ， libart libc ， libart < /code>， libbase 和 libandroid_runtime 。

我们有一些棘手的崩溃，这些崩溃完全在Android运行时发生，而这些崩溃很难在没有符号的情况下进行调试。在firebase crashlytics中，我们看到以下堆栈跟踪：

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

当我通过删除无效指针在我们的C ++库中迫使测试崩溃时，我在本地Android Studio 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...

：

...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...

但是，Crashlytics中的同样崩溃看起来像这样我们可以得到Crashlytics以包含CrashDump中明显的信息吗？

我们的构建设置上的一些注释：

我们已经遵循 https：//firebase.google.com /docs/crashlytics/ndk-reports
gradle项目1构建本地库，确保调试已打开并且符号未剥离。
Gradle Project 2在库中构建应用程序和链接，并告诉Crashlytics上传本机符号

            firebaseCrashlytics {
                nativeSymbolUploadEnabled true
                unstrippedNativeLibsDir file("PATH/TO/UNSTRIPPED/DIRECTORY")
            }

原文

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")
            }

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

半暖夏伤 2025-02-16 12:50:55

期望这种行为。当crashlytics发生NDK崩溃时，这些需要象征性。为此，应将各个符号文件上传到crashlytics。

通过提到的配置，应用程序中可用的符号将上传到Crashlytics。

nativeSymbolUploadEnabled true

但是对于系统库，各自的符号文件不可用（据我所知，它们不是公开的）。因此，crashlytics无法访问所需的符号文件，用于从系统库中的象征帧。

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.

回复收藏 0 原文