Debug Android native code

Introduction

     How to debug native code running on emulator/devices?    There are  some tools both in AOSP and system.image that can be used to achieve the aim.

  • device side:   /system/bin/gdbserver
  • AOSP side :   NDK,   prebuild/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-gdb   

    The baisc idea is using adb to route gdb command between  x86 and android device, below is a rude demonstration:

 

How to using GDB debugging android

step1: use adb shell ps to list process list,  and select which process want to debug, for example android.com.media whose pid=668

# adb shell ps


step2:  run gdbserver with a given tcp port,  for example port 10000

# adb shell gdbserver :10000 --attach 668

Attached; pid=quit

Listening on port 10000


step3: run adb to forward port 10000 to target devices

# adb forward tcp:5039 tcp:10000     //replace 5039 with the real listen port of adb server


step4: run gdb in NDK

# prebuild/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-gdb


step5:  connect gdb to gdbserver,   run gdb command 

(gdb) target remote localhost:5039

 

 

 

<think>好的,我现在需要帮助用户找到关于Linux和Android环境下分析Native Crash的工具和方法。首先,我需要回忆一下之前用户提供的引用内容,里面提到了tombstone文件、ndk-stack、addr2line、objdump,还有Bugly这样的第三方工具。 用户的问题很明确,是要了解分析Native Crash的具体工具和方法。根据引用资料,首先应该提到tombstone文件,这是系统生成的崩溃日志,位置在/data/tombstones/,需要root权限才能访问。然后,解析这些文件需要用到的工具,比如ndk-stack,这是NDK自带的工具,可以将堆栈跟踪符号化,帮助定位问题。另外,addr2line和objdump也是常用的工具,用于将地址转换为代码行和查看反汇编代码。 接下来,用户可能需要知道具体的步骤,比如如何获取tombstone文件,如何使用ndk-stack进行分析。还有可能需要提到如何在没有root权限的情况下通过adb logcat获取崩溃日志,或者使用第三方工具如Bugly来简化流程。 还要考虑用户可能遇到的困难,比如如何设置符号文件路径,或者如何处理没有符号的情况。需要分步骤说明,确保用户能一步步操作。此外,引用中提到的信号机制和常见错误类型,比如SIGSEGV、SIGABRT等,可能也是用户需要了解的内容,需要简要说明。 最后,生成相关问题时要围绕工具使用、常见错误分析、优化方法、第三方工具比较等方面,帮助用户扩展相关知识。</think>### Linux/Android Native Crash 分析工具与方法 #### 一、核心分析工具 1. **tombstone文件** Native Crash发生时,系统会在路径 `/data/tombstones/` 下生成 `tombstone_xx` 文件,包含崩溃时的寄存器状态、堆栈调用链、内存映射表等关键信息[^2][^4]。 **获取方式**: - 通过 `adb pull /data/tombstones/tombstone_xx` 导出(需设备root权限) - 若无root权限,可通过 `adb logcat` 筛选崩溃日志中的关键堆栈。 2. **ndk-stack** NDK官方提供的符号化工具,能将崩溃日志中的内存地址转换为可读的代码位置[^4]。 **使用方法**: ```bash ndk-stack -sym <符号文件路径> -dump tombstone_xx ``` 符号文件需包含编译时生成的 `.so` 文件(带调试符号的版本)。 3. **addr2line与objdump** - **addr2line**:将地址映射到源码行号 ```bash arm-linux-androideabi-addr2line -e <so文件路径> <崩溃地址> ``` - **objdump**:反汇编代码,分析指令逻辑 ```bash arm-linux-androideabi-objdump -d <so文件路径> > disassembly.txt ``` 4. **第三方工具Bugly** 提供符号化、堆栈还原、上下文环境参数(如设备信息、内存状态)等一站式分析功能[^3],适合无符号文件或需要快速定位的场景。 --- #### 二、分析流程 1. **提取崩溃日志** - 优先获取完整的 `tombstone_xx` 文件[^2] - 若无权限,从 `adb logcat | grep "DEBUG"` 中提取关键堆栈。 2. **符号化堆栈** - 使用 `ndk-stack` 对日志整体符号化[^4] - 若需精准定位,用 `addr2line` 单独解析关键地址。 3. **分析崩溃原因** - **常见信号类型**: - `SIGSEGV`:非法内存访问(空指针、缓冲区溢出) - `SIGABRT`:主动调用 `abort()` 或断言失败 - **内存映射表分析**:检查崩溃地址所属模块(如 `.so` 或系统库)。 4. **复现与调试** - 使用 `gdb/lldb` 附加到进程进行动态调试 - 结合 `strace` 跟踪系统调用。 --- #### 三、实战示例 以 `SIGSEGV` 崩溃为例: 1. 从 `tombstone` 中定位崩溃线程堆栈: ``` signal 11 (SIGSEGV), code 1 (SEGV_MAPERR) r0 00000000 r1 00000001 pc a1b2c3d4 libnative.so ``` 2. 符号化地址 `a1b2c3d4`: ```bash addr2line -e libnative.so a1b2c3d4 ``` 输出结果指向 `native_code.c:45`,检查该行是否存在空指针解引用。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值