<think>我们正在
分析Android的
Tombstone日志。根据之前的对话和引用，我们已经介绍了解析方法和工具。用户现在想了解如何
分析Tombstone日志，我们需要提供详细的
分析步骤和关键点。
关键点：
1.
Tombstone日志的产生：当Native层（C/C++代码）发生崩溃时，系统会生成
Tombstone文件，保存在/data/
tombstones/目录下（需要root权限访问）[^2][^3]。
2. 日志内容：包含崩溃信号、寄存器状态、堆栈回溯、内存映射等关键信息[^2][^4]。
3.
分析步骤：通常包括获取日志、准备符号文件、符号化堆栈、定位崩溃原因。
根据引用[4]，详细
分析Tombstone日志需要关注：
- 崩溃信号（如SIGSEGV, SIGABRT等）和错误码（如SEGV_MAPERR, SEGV_ACCERR等）
- 崩溃地址（fault addr）
- 寄存器状态（特别是pc和lr寄存器）
- 堆栈回溯（backtrace）
- 内存映射（memory map near fault address）
我们按照以下结构回答：
一、获取
Tombstone日志
二、理解
Tombstone日志的结构
三、符号化堆栈回溯
四、
分析崩溃原因
五、常见错误类型及解决方法
同时，生成相关问题。</think>###
Tombstone日志
分析详解
#### 一、获取与
分析步骤
1. **获取日志文件**
```bash
adb pull /data/
tombstones/
tombstone_00 # 需root权限
```
日志存储在设备`/data/
tombstones/`目录，文件名如`
tombstone_00`[^2]
2. **关键结构解析**
```
log
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'Xiaomi/...' # 设备信息
Signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 # 崩溃信号
r0 00000000 r1 00000001 ... pc e9ed4c08 # 寄存器状态
backtrace: # 堆栈回溯（核心
分析点）
#00 pc 0001a234 /system/lib/libutils.so
#01 pc 0000b5d8 /system/lib/libbinder.so
memory map near fault addr 0x0: # 内存映射
00000000-00001000 r-- /dev/mem (deleted)
```
[^2][^4]
---
#### 二、核心
分析要点
1. **崩溃信号解析**
- `SIGSEGV (signal 11)`：内存非法访问（空指针/越界）
- `SIGABRT (signal 6)`：程序主动终止（assert失败）
- `fault addr 0x0`：典型空指针访问[^4]
2. **寄存器关键值**
- `pc`(程序计数器)：崩溃时执行的指令地址
- `lr`(链接寄存器)：函数返回地址
- `sp`(栈指针)：当前栈位置
```
log
pc 0001a234 lr 800b5d8 sp ff0000a0
```
3. **堆栈回溯
分析**
使用符号文件解析地址：
```bash
# 使用addr2line解析
arm-linux-
androideabi-addr2line -e libutils.so 0001a234
# 输出：_ZNK7
android6Parcel9readInt32Ev+24 (Parcel.cpp:120)
```
[^4]
4. **内存映射
分析**
```
log
memory map near fault addr 0xdead0000:
12c00000-12d00000 rw- # 可读写内存段
40000000-40004000 r-x /system/lib/libc.so # 代码段
```
检查崩溃地址是否在合法内存范围内[^4]
---
#### 三、符号化工具对比
| 工具 | 命令示例 | 适用场景 |
|------|----------|----------|
| **ndk-stack** | `ndk-stack -sym obj/local/armeabi-v7a/ -dump
tombstone` | 快速完整解析 |
| **addr2line** | `addr2line -e lib.so <address>` | 单地址解析 |
| **GDB** | `gdb -ex "set solib-search-path symbols" -ex "target remote :1234"` | 动态调试 |
| **stack脚本** | `./development/scripts/stack
tombstone_00` | 需完整源码环境[^3] |
> 示例：ndk-stack解析
> ```bash
> ndk-stack -sym project/obj/local/armeabi-v7a/ -dump
tombstone_00
> ```
---
#### 四、常见崩溃原因
1. **空指针访问**
`fault addr 0x0` + `SIGSEGV code 1` → 解引用空指针
2. **内存越界**
```
log
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR)
fault addr 0x7f5d3a0000 # 非法地址
```
3. **栈溢出**
`backtrace`中出现重复递归调用
4. **资源竞争**
多线程访问共享资源未加锁
---
#### 五、无源码环境
分析技巧
1. 使用`objdump`反汇编：
```bash
arm-linux-
androideabi-objdump -d lib.so > disassembly.txt
```
2. 在反汇编中搜索崩溃地址附近的指令
3. 结合寄存器状态
分析内存操作指令（如`LDR`, `STR`）
> ⚠️ 注意：符号文件必须与崩溃时的二进制完全匹配（编译版本、ABI架构）[^4]
文章讲述了在Android系统中遇到的Tombstone问题，这是由Dalvik错误、C层代码问题等引起的。作者分析了两种情况：pid与tid相同的问题通常发生在主线程，而pid与tid不同的问题可能涉及系统服务进程。通过信号量分析和日志对比，可以定位问题源头，但过程可能复杂。文章提供了相关链接以供进一步学习。
最低0.47元/天 解锁文章
扫一扫
2282
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
