如何利用 release 版本的 backtrace 来定位 android NDK 程序的崩溃位置

我们知道 android NDK 程序在崩溃时会生成一个 tombstone 的 backtrace (也可利用 ADB logcat 抓取),从这个 backtrace 中我们可以了解是哪个函数引发的崩溃,但是通常由于我们发布时都是 release 版,无法利用 backtrace 中的地址信息直接定位到源码和行号,当引发崩溃的错误不是很明显时,对于我们解决问题的帮助就不大。

这时通常我们是重编一个 debug 版本并设法重现 crash。这样做有个两个问题,一是如果我们不知道复现步骤,或者复现概率很低时,效率不高;二是我们不一定总能满足 crash 产生的条件,而一旦版本发布后,使用 debug 版本去替换用户场景中的 release 版又非常麻烦(甚至可能无法实现)。

事实上,有一个办法可以解决这个问题。我们知道,release 版本的库文件也是有 DYNAMIC SYMBOL TABLE 的,你可以使用命令 objdump -T -R <your so> (并重定向到一个文本文件中)来查看,然后你可以用同样的命令去查看 debug 版本的 DYNAMIC SYMBOL TABLE,通过比较,不难发现,他们的格式是一样的,你需要关注的只是第一列(symbol address)和最后一列(symbol name)。

接下来,你在 debug 版本的 DYNAMIC SYMBOL TABLE 中搜索引发崩溃的函数名,并记下它的 symbol address,然后,你只需要在这个地址上增加一个偏移量,就可以使用 addr2line 命令来定位源码和行号了。这个偏移量是多少?请注意 backtrace 中 #00  pc 的最后一列(使用括号括住),其中在函数名的后面有一个+N,这个N就是崩溃位置的偏移量(注意它是10进制数,而 symbol address 是16进制数,你需要先做转换才能相加)。

需要说明的是,由于 release 版通常都经过了优化,backtrace 中的偏移量并不一定非常准确,但离实际值差得不会太远,你可以使用 debug 版做一个对比测试就可以验证。现在你可以去试试这个方法了,希望这个方法能帮助你提高解决 crash 问题的效率。


如何利用 release 版本的 backtrace 来定位 android NDK 程序的崩溃位置,布布扣,bubuko.com

如何利用 release 版本的 backtrace 来定位 android NDK 程序的崩溃位置

上一篇:成功解决TypeError: Value passed to parameter 'paddings' has DataType float32 not in list of al


下一篇:Android中关于JNI 的学习(三)在JNI层访问Java端对象