拿到死机backtrace堆栈后如何确认死在哪一行源码（ARM+Android平台反汇编分析举例）

目录

Android上如何用debuggerd拿到死机堆栈

拿到死机堆栈后如何分析

分析backtrace文件

反汇编分析.so文件

反汇编分析.o文件

相关附件

---

Android上如何用debuggerd拿到死机堆栈

关于debuggerd的原理，在这里就不赘述了。

需要注意两点：

1，确保要调试的进程中没有重写信号处理函数。

在我们的中间件中，libqin_buslib.so中，重写了信号处理函数，这样会覆盖系统默认的信号处理函数，导致debuggerd无法捕获信号。

修改方法：

common_lib/buslib/src/bus_main.c，将bus_ctrl_init()函数内的如下一行代码注释掉：

bus_ctrl_init() {

...

//bus_ctrl_ShutdownInit();

... }

然后重新编译common_lib仓库，将新的libqin_buslib.so放入机顶盒内的相关路径中。

 

2，确保 /data/tombstones/目录已存在。

如果该目录不存在，那么debuggred无法将堆栈写入tombstone文件。

必要时手动创建：

mkdir /data/tombstones

死机后的堆栈信息，将被debuggerd写入 /data/tombstones/中

 

拿到死机堆栈后如何分析

我们知道，只要拿到的backtrace中有函数信息，我们就可以找到死机对应的大体位置，通过添加多行打印的方法，来一点点逼近死机位置。

但是，这种方法也有他的局限性：

• 效率不够高，特别是针对小概率死机问题
• 添加了多行打印后，有可能影响多线程的运行时序，导致死机更难复现
• 不够高大上

因此，拿到第一次backtrace后就能精准定位死机位置的方法，才是高大上的方法。

 

分析backtrace文件

backtrace-05的死机堆栈：

backtrace:

#00 pc 00000d3c /system/lib/libqin_playerportbc.so

#01 pc 00001a94 /system/lib/libqin_playerportbc.so (istb_porting_player_open+1180)

 

当前函数#00的PC是0xd3c，外层调用函数#01的pc是1a94（返回地址是1a98），因此，0xd3c和0x1a94处到底指的是哪一行源码，是我们要求证的终极目标。