Android JNI 异常定位（2）—— addr2line

原创 已于 2023-11-22 17:43:39 修改 · 1.1k 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#jni #addr2line

于 2023-11-22 17:34:30 首次发布
本文介绍了Android设备中遇到信号11(SIGSEGV)报错时，如何利用/data/tombstones中的堆栈信息和addr2line工具定位子线程崩溃的问题，强调了addr2line在解析异常地址的重要性。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

Android native报错有时候只有一句 signal 11 (SIGSEGV)，这种情况仅通过log是很难定位到问题的。不过Android 在/data/tombstones目录保存了错误的堆栈信息，为定位bug提供了路径。不过一般这里的log都无法像java一样直接定位的出错的行数。如下图：

--------- beginning of crash
11-21 11:31:40.633 F/libc    ( 1127): Fatal signal 11 (SIGSEGV), code 1, fault addr 0xcbb45812 in tid 1260 (RenderThread)
11-21 11:31:40.633 W/        (  203): debuggerd: handling request: pid=1127 uid=1000 gid=1000 tid=1260
11-21 11:31:40.646 E/JNI_MANAGER( 1127): WebRtcAecm_BufferFarend
11-21 11:31:40.647 E/JNI_MANAGER( 1127): WebRtcAecm_BufferFarend
11-21 11:31:40.731 F/DEBUG   ( 2352): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
11-21 11:31:40.732 F/DEBUG   ( 2352): Build fingerprint: 'Android/rk3288/rk3288:7.1.2/NHG47K/zoeyli08041021:userdebug/test-keys'
11-21 11:31:40.732 F/DEBUG   ( 2352): Revision: '0'
11-21 11:31:40.733 F/DEBUG   ( 2352): ABI: 'arm'
11-21 11:31:40.734 F/DEBUG   ( 2352): pid: 1127, tid: 1260, name: RenderThread  >>> com.intercom.supervisor <<<
11-21 11:31:40.734 F/DEBUG   ( 2352): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xcbb45812
11-21 11:31:40.735 F/DEBUG   ( 2352):     r0 7f1d9fc0  r1 900f4ef8  r2 cbb457f2  r3 01000000
11-21 11:31:40.735 F/DEBUG   ( 2352):     r4 900f4f20  r5 7ed04880  r6 00000004  r7 00000001
11-21 11:31:40.736 F/DEBUG   ( 2352):     r8 7ed04830  r9 900f4f60  sl 900f4f20  fp 00000001
11-21 11:31:40.736 F/DEBUG   ( 2352):     ip a358dba8  sp 900f4ef0  lr a1d558b0  pc a1d5f518  cpsr 20070010
11-21 11:31:40.750 W/AudioFlinger(  234): RecordThread: buffer overflow
11-21 11:31:40.794 F/DEBUG   ( 2352): 
11-21 11:31:40.794 F/DEBUG   ( 2352): backtrace:
11-21 11:31:40.794 F/DEBUG   ( 2352):     #00 pc 0043e518  /vendor/lib/egl/libGLES_mali.so
11-21 11:31:40.794 F/DEBUG   ( 2352):     #01 pc 004348ac  /vendor/lib/egl/libGLES_mali.so
11-21 11:31:40.794 F/DEBUG   ( 2352):     #02 pc 00326090  /vendor/lib/egl/libGLES_mali.so
11-21 11:31:40.794 F/DEBUG   ( 2352):     #03 pc 00323b1c  /vendor/lib/egl/libGLES_mali.so
11-21 11:31:40.794 F/DEBUG   ( 2352):     #04 pc 00447a60  /vendor/lib/egl/libGLES_mali.so
11-21 11:31:40.794 F/DEBUG   ( 2352):     #05 pc 00455750  /vendor/lib/egl/libGLES_mali.so
11-21 11:31:40.795 F/DEBUG   ( 2352):     #06 pc 004503dc  /vendor/lib/egl/libGLES_mali.so
11-21 11:31:40.795 F/DEBUG   ( 2352):     #07 pc 0044e8b8  /vendor/lib/egl/libGLES_mali.so
11-21 11:31:40.795 F/DEBUG   ( 2352):     #08 pc 0044f18c  /vendor/lib/egl/libGLES_mali.so
11-21 11:31:40.795 F/DEBUG   ( 2352):     #09 pc 0044f260  /vendor/lib/egl/libGLES_mali.so
11-21 11:31:40.795 F/DEBUG   ( 2352):     #10 pc 003ab1ac  /vendor/lib/egl/libGLES_mali.so
11-21 11:31:40.795 F/DEBUG   ( 2352):     #11 pc 0038664c  /vendor/lib/egl/libGLES_mali.so
11-21 11:31:40.795 F/DEBUG   ( 2352):     #12 pc 00695288  /vendor/lib/egl/libGLES_mali.so
11-21 11:31:40.796 F/DEBUG   ( 2352):     #13 pc 0069e3bc  /vendor/lib/egl/libGLES_mali.so (eglMakeCurrent+1488)
11-21 11:31:40.796 F/DEBUG   ( 2352):     #14 pc 0000ac41  /system/lib/libEGL.so (_ZN7android13egl_display_t11makeCurrentEPNS_13egl_context_tES2_PvS3_S3_S3_S3_S3_+192)
11-21 11:31:40.796 F/DEBUG   ( 2352):     #15 pc 0000d497  /system/lib/libEGL.so (eglMakeCurrent+290)
11-21 11:31:40.796 F/DEBUG   ( 2352):     #16 pc 000263e9  /system/lib/libhwui.so
11-21 11:31:40.796 F/DEBUG   ( 2352):     #17 pc 0002667d  /system/lib/libhwui.so
11-21 11:31:40.796 F/DEBUG   ( 2352):     #18 pc 0002344b  /system/lib/libhwui.so
11-21 11:31:40.796 F/DEBUG   ( 2352):     #19 pc 00023339  /system/lib/libhwui.so
11-21 11:31:40.796 F/DEBUG   ( 2352):     #20 pc 000272e5  /system/lib/libhwui.so
11-21 11:31:40.797 F/DEBUG   ( 2352):     #21 pc 00028117  /system/lib/libhwui.so
11-21 11:31:40.797 F/DEBUG   ( 2352):     #22 pc 00028857  /system/lib/libhwui.so
11-21 11:31:40.797 F/DEBUG   ( 2352):     #23 pc 00029139  /system/lib/libhwui.so (_ZN7android10uirenderer12renderthread12RenderThread10threadLoopEv+80)
11-21 11:31:40.797 F/DEBUG   ( 2352):     #24 pc 0000e325  /system/lib/libutils.so (_ZN7android6Thread11_threadLoopEPv+144)
11-21 11:31:40.797 F/DEBUG   ( 2352):     #25 pc 00067f29  /system/lib/libandroid_runtime.so (_ZN7android14AndroidRuntime15javaThreadShellEPv+80)
11-21 11:31:40.797 F/DEBUG   ( 2352):     #26 pc 00047323  /system/lib/libc.so (_ZL15__pthread_startPv+22)
11-21 11:31:40.797 F/DEBUG   ( 2352):     #27 pc 00019e5d  /system/lib/libc.so (__start_thread+6)
11-21 11:31:41.277 I/AudioFlinger(  234): BUFFER TIMEOUT: remove(4098) from active list on thread 0xad983d00
11-21 11:31:41.742 E/        ( 2352): debuggerd: failed to kill process 1127: No such process
11-21 11:31:41.748 W/        (  203): debuggerd: resuming target 1127
11-21 11:31:41.750 I/BootReceiver(  485): Copying /data/tombstones/tombstone_05 to DropBox (SYSTEM_TOMBSTONE)
  • 先看崩溃的tid:1260，不是主线程，说明是子线程。
  • 最后一行/data/tombstones/tombstone_05提示异常日志保存在了tombstone_05文件里面
    在这里插入图片描述

backtrace需要借助Android ndk提供的addr2line工具来分析，从工具的名字就能看出来，这个东西可以帮我们把报错的地址指向代码行，以协助我们排查问题。
看工具的使用方式：

1.找到本地ndk路径下的addr2line的程序

我的路径“D:\Android\ndk\android-ndk-r10e\toolchains\aarch64-linux-android-4.9\prebuilt\windows-x86_64\bin”
在这里插入图片描述
这里需要注意toolchains下根据系统架构区分多个目录，需要根据自己运行的系统进行区分，否则会报File format not recognized 错误。我的是64位系统，所以选了图示目录

在这里插入图片描述

2.打开命令行跳转至该目录

2.1、直接在路径下输入cmd,然后按enter键，就可以直接打开命令行窗口，并且跳转到该路径下面

在这里插入图片描述
在这里插入图片描述

3.使用addr2line -e命令

aarch64-linux-android-addr2line -e D:\Android\AndroidStudio\Project\ManagerJni\obj\local\armeabi\intercomManager.so 00019e5d

在这里插入图片描述

  • 红色1、so库必须是带有符号表的
  • 红色2、为异常的地址
  • 最后一行就转换出了异常所在的行
Android 调试中使用 addr2line 命令
PixelNinja的博客
10-08 1311
在 Android 开发过程中，调试是一个非常重要的环节。在编译 Android 应用程序时，默认情况下是不会生成调试符号表的。因此，我们需要在构建过程中添加相应的选项来生成调试符号表。命令可以将程序崩溃时的内存地址转换为对应的源代码位置。这对于定位崩溃点非常有帮助，特别是在没有调试符号表的情况下。通过将内存地址转换为源代码位置，我们可以更方便地定位问题的根源，从而加速调试过程。命令之前，需要确保已经生成了调试符号表，并获取到崩溃点的内存地址。命令的使用方法，并提供相应的源代码示例。是崩溃点的内存地址。
Android so库开发——addr2line查看so异常信息（四）
小旭的专栏
01-13 3282
在NDK开发中经常会出现应用Crash的情况，而JNI层的报错信息，不像Java层报错信息那样可以直接在日志中看到错误的行数，JNI层中出现的错误直接看根本定位不到错误的位置。通常来说，JNI报的基本都是堆栈信息，需要NDK的一些工具进行地址转换，转换后即可看到错误的位置。addr2line就是这些地址转换的工具。
Android addr2line 工具使用
u014630142的博客
08-13 2175
address2line 工具使用
使用addr2line工具排查报错堆栈
最新发布
qq_34341546的博客
06-18 282
内核出现pannic，空指针等问题是会出现堆栈打印，可以通过堆栈来定位具体的代码，这时候我们需要内核编译的 vmlinux，如果重新编译的话，符号表会更新，就无法定位。安卓对应的so库奔溃的话，也可以通过addr2line来定位问题点。
addr2line命令
热门推荐
06-13 7万+
在Linux下写C/C++程序的程序员，时常与Core Dump相见。在内存越界访问，收到不能处理的信号，除零等错误出现时，我们精心或不精心写就的程序就直接一命呜呼了，Core Dump是Linux仁慈地留下的程序的尸体，帮助程序员们解决了一个又一个问题。 有时配置不给力，Linux直接毁尸灭迹，没有了Core文件；又有时，刚好磁盘空间不足，Core文件写不下了。没有Core文件的时候，如何知道
Android使用addr2line分析Native Crash
薛文旺
09-02 1759
从foo()转换为_Z3foov的过程被称为mangle，_Z3foov转换为foo()的过程被称为demangle。这里展开说说-C这个参数，我们知道C/C++语言在编译以后，函数的名字会被编译器修改为编译器内部识别的名字，该名字在链接的时候被用到。常用的地址转换工具有addr2line、ndk-stack等，个人比较喜欢addr2line，所以接下来介绍下该工具的基本使用方式。我们主要关注backtrace后面的信息，同时带"pc"和"/data"的行基本就是app相关的崩溃行了。
android addr2line使用
qq_37610155的博客
12-15 7144
一般碰到NE的异常需要通过addr2line把异常地址转成code文件和行号。 1.进入到prebuilts/gcc/linux-x86/arm/cit-arm-linux-androideabi-4.8目录， 2.把libunwind.so从\out\target\product\XXX\symbols下面去找到该库文件，并把该so拷贝到cit-arm-linux-androideabi
Android 使用addr2line分析so异常
wolf0706的专栏
09-05 1712
要在 Android 中使用 addr2line 工具进行问题分析，你需要获取崩溃堆栈信息，并识别其中的程序地址。然后，使用 addr2line 工具将程序地址转换为源代码位置。如：ndk\21.4.7075529\toolchains\aarch64-linux-android-4.9\prebuilt\windows-x86_64\bin。在 Android 开发中，addr2line 是一个用于将程序地址转换为源代码位置的工具。它通常用于分析崩溃日志或错误报告，以确定问题的源代码位置。
Android studio中NDK开发（四）——使用addr2line分析Crash日志
Xiongjiayo的博客
01-17 1万+
一、前言 在NDK开发中经常会出现应用Crash的情况，而JNI层的报错信息，不像Java层报错信息那样可以直接在日志中看到错误的行数，JNI层中出现的错误直接看根本定位不到错误的位置。通常来说，JNI报的基本都是堆栈信息，需要NDK的一些工具进行地址转换，转换后即可看到错误的位置。这些地址转换的工具有addr2line、ndk-stack等，我比较喜欢addr2line，平时也用这个工具进行调试...
JNI——Android Native代码的内存泄漏问题
Yawn
06-23 791
利用开源的LeakTracer项目可以打印出内存的调用栈，从而发现内存泄漏问题。 首先下载LeakTracer的代码LeakTracer.zip，在这里为大家准备好了一份，见我的资源。 然后将代码解压至AS的JNI目录下，即native代码的第一层。 将LeakTracer的相关文件导入CMake 在代码块的开端添加头文件 并在主函数中的开头和结尾添加如下代码，即start和stop抓取的操作 这样就可以在指定目录得到一个文件，里面记录了所以未释放的内存调用信息，里面全都是地址信息，需要对so进
Android Native 异常捕获库_android捕获native异常so库
xcbyaya的博客
04-26 233
可以使用ndk中的add2line工具根据pc值和带符号信息的so库，定位出具体代码行数。
Android日志实战——Tombstones日志分析（七）
小旭的专栏
07-07 2110
Tombstones 一般是由 Dalvik 错误、状态监视调试器、C 层代码以及 libc 的一些问题导致的。当系统发生 Tombstone 的时候，内核（kernel）首先会上报一个严重的警告信号（signal），上层接收到之后，进程的调试工具会把进程中当时的调用栈现场保存起来，并在系统创建了 data/tombstones 目录后把异常时的进程信息写在此目录里面，开发者需要通过调用栈来分析整个调用流程来找出出问题的点。Tombstone原因分析pid 与 tid 相同，问题出在主线程。
Android日志报错地址定位函数 addr2line
daisy.skye的博客
12-05 1320
目录crash报错日志使用addr2line 显示 ??:0 问题排查总结（可以直接看这） 解析日志 直接定位到 backtrace ，linux编译的终端切换到out输出路径下（因为整个机子是基于系统进行的工作，而系统是linux编译后输出到out目录下，所以在out目录下排查问题就可以了）然后使用 addr2line 进行查看错误地址的原代码位置 使用addr2line 显示 ??:0 问题排查 一般是文件路径没有加文件路径不对 相对地址不对find | grep使用前查看筛选文件路径在ou
Android中使用addr2line来分析native信息
andy_android的专栏
02-28 2万+
系统：Ubuntu12.04 手机系统：Android5.0 在Android的开发过程中有会有很多的native bug必须要用addr2line来分析，并且这个工具也非常的好用。下面我们来看看具体的使用。 烧录到手机上的版本和你电脑上的编译出的版本要一致，这个数据才是准确的，才好定位到那一行。 首先找到自己电脑可用的addr2line，用命令find . -name *addr2lin
Android知识点 401 -- addr2line
编程到管理、技术到产品
07-16 416
文章原文：https://www.jianshu.com/p/c2e2b8f8ea0d 返回知识列表：Android知识列表 addr2line工具是一个可以将指令的地址和可执行映像转换为文件名、函数名和源代码行数的工具。这在内核执行过程中出现崩溃时，可用于快速定位出出错的位置，进而找出代码的bug。 用法 addr2line [-a| --addresses ] [-b bfdname | --target=bfdname] [-C | --demangle[=style]] [-e filena
android 调试中 addr2line 命令的使用
vapl32的专栏
03-12 775
关于调试：调试中addr2line命令的使用。 问题引出：i850的wifi定位开启后，在使用goole maps时出现rootfs重启现象，打印的log信息如下： ／／／／／／／／／／／／／／／／／／／／／／／／／／ I/DEBUG   ( 3411): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** I/D
android addr2line 用法,Android studio中NDK开发（四）——使用addr2line分析Crash日志
weixin_39839410的博客
05-29 1383
一、前言在NDK开发中经常会出现应用Crash的情况，而JNI层的报错信息，不像Java层报错信息那样可以直接在日志中看到错误的行数，JNI层中出现的错误直接看根本定位不到错误的位置。通常来说，JNI报的基本都是堆栈信息，需要NDK的一些工具进行地址转换，转换后即可看到错误的位置。这些地址转换的工具有addr2line、ndk-stack等，我比较喜欢addr2line，平时也用这个工具进行调试。...
android addr2line
u012497906的专栏
04-26 485
backtrace:    #00 pc 000351c4  /system/lib/libgui.so (_ZN7android19BufferQueueConsumer13releaseBufferEiyRKNS_2spINS_5FenceEEEPvS6_+475)    #01 pc 000360b9  /system/lib/libgui.so    #02 pc 0003b259  /s...
android调试工具addr2line使用补充
kukuqiu001的专栏
09-08 261
参考自 [url]http://blog168.chinaunix.net/space.php?uid=20564848&do=blog&id=94732[/url] 使用addr2line追踪自有动态库(so文件)的bug, 补充: 解决出现 ??:0 , 没法展示源代码行数的问题 在Android.mk 文件中: [code="java"] LOCAL_CFLAGS := ...
windows addr2line
03-14
<think>嗯，用户想在Windows环境下使用addr2line工具，我需要先回忆一下addr2line的作用和相关配置步骤。addr2line主要是用来将程序崩溃时的地址转换成源代码的位置，帮助调试。根据用户提供的引用信息，引用[4]提到addr2line可以将地址转换为文件名、函数名和行号，这在处理崩溃时非常有用。 首先，用户需要知道如何在Windows上获取这个工具。根据引用[1]、[2]、[3]，addr2line通常包含在交叉编译工具链里，比如ARM开发工具链或NDK中。比如，引用[3]指出NDK中的路径是ndk\toolchains\aarch64-linux-android-4.9\prebuilt\windows-x86_64\bin，里面可能有arm-linux-androideabi-addr2line.exe这样的工具。所以用户需要安装NDK或者相关的工具链来获取该工具。 接下来，配置环境变量。用户可能需要将工具所在的目录添加到系统PATH中，或者在命令中直接指定完整路径。例如，如果工具在C:\ndk\...\bin目录下，可以通过cd命令进入该目录，或者使用绝对路径执行addr2line。 然后，使用命令时需要注意参数。根据引用[5]，基本命令格式是addr2line -e <可执行文件> <地址>。在Windows中，可能需要使用反斜杠或双引号处理路径中的空格。例如，-e选项指定带符号的可执行文件（如ELF格式），然后输入地址。如果是动态库，可能需要使用对应的工具版本，如引用[2]提到的32位动态库使用arm-linux-androideabi-addr2line.exe。 还要注意，生成的可执行文件或库必须包含调试符号，即编译时使用-g选项，否则addr2line无法解析地址。用户可能遇到的问题是找不到符号，这时候需要确认是否编译时包含了调试信息。 另外，用户可能需要处理多个地址的情况，可以逐个输入或用管道传递。例如，在崩溃日志中有多个地址，可以用脚本批量处理。 总结步骤：安装工具链（如NDK），配置工具路径，使用正确的命令格式，并确保有调试符号。同时，用户可能需要根据不同的架构选择对应的addr2line版本，比如arm-none-eabi-addr2line或aarch64-linux-android-addr2line，如引用[1]、[3]所述。 最后，验证步骤是否正确，例如运行工具查看输出来源文件和行号。如果出现错误，检查路径是否正确，可执行文件是否匹配地址对应的架构，以及是否有调试信息。</think>### 如何在 Windows 系统中使用 addr2line 工具 #### 步骤 1: 获取 addr2line 工具 - **通过 NDK 工具链获取** 根据引用[3]，addr2line 工具位于 NDK 的 `toolchains` 目录下，例如： `ndk\toolchains\aarch64-linux-android-4.9\prebuilt\windows-x86_64\bin\aarch64-linux-android-addr2line.exe` 若需解析 32 位程序地址，使用 `arm-linux-androideabi-addr2line.exe`（引用[2]）。 - **通过 ARM 开发工具链获取** 某些工具链（如 STM32 开发工具）可能包含 `arm-none-eabi-addr2line.exe`（引用[1]）。 #### 步骤 2: 配置环境变量（可选） 将工具所在目录（如 NDK 的 `bin` 目录）添加到系统 `PATH` 环境变量，方便直接调用工具。 #### 步骤 3: 使用命令解析地址 基本命令格式为（引用[5]）： ```bash addr2line.exe -e <可执行文件路径> <内存地址> ``` **示例**： ```bash aarch64-linux-android-addr2line.exe -e my_app 0x4009a8 ``` #### 步骤 4: 关键注意事项 1. **调试符号要求** 可执行文件或动态库需包含调试符号（编译时添加 `-g` 选项），否则无法解析源码位置（引用[4]）。 2. **架构匹配** 工具需与程序架构一致（如 ARM、x86_64），否则解析结果错误。 *例如：ARM 程序需使用 `arm-linux-androideabi-addr2line.exe`（引用[2]）。* 3. **路径处理** Windows 路径若含空格，需用双引号包裹： ```bash addr2line.exe -e "C:\Program Files\my_app\app.elf" 0x4009a8 ``` #### 验证示例 假设崩溃日志中的地址为 `0x804a3d`，使用 STM32 工具链解析： ```bash arm-none-eabi-addr2line.exe -e firmware.elf 0x804a3d ``` 输出结果为源码文件名和行号，例如： `main.c:42` ---
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值