tombstone分析笔记01 - 反汇编篇

．　android问题处理中，经常遇到的就是tombstone问题。tombstone的分析与linux中分析coredump相似，两者的不同点在于，coredump通过gdb可以分析到完整的环境信息，但tombstone则不行，我们所能得到的信息都呈现在tombstone这个文件中，也因此充分利用好这个文件的信息，往往能帮我们节省很多压测需求。从这篇文章开始，我将总结遇到过的一些tombstone问题的分析过程，记录以便未来进一步系统化问题处理思路。

异常系统信息：32bit Android P，64bit Kernel 4.9 arm架构
复现方式：monkey压测一通宵可复现到system_server native crash的问题。

．　首先需要确认的是如下的tombstone头部信息，这里是整个分析的起点，也是我们需要重视的地方。　　
　　我们最先关注的signal和trace信息，signal能了解发生了什么，trace则让我们明确调用flow是怎么样的，是在哪里发生的异常。如上trace我们可以看到是SIGSEGV，段错误，非法地址访问的问题，明确是这类问题后，我们一般第一步要做的就是执行下addr2line，看下异常发生在哪一行，以此推断是什么变量或者操作触发异常。

　　通过tombstone的build fingerprint明确异常软件的版本信息，抓取异常版本的编译symbols文件。通过结合tombstone trace中so文件的位置信息，我们可以通过如下方式定位异常代码位置。反汇编出来的位置跟我们想象的不一样，是落在atomic中，不是addOrUpdateStream中，这样是不是意味着trace异常了呢？并不是，这里打出来的位置是准确的，具体原因我们继续往下分析：

arm-linux-androideabi-addr2line -f -e libandroid_servers.so -a 0x48224

　　通过addr2line我们看到的是准确的代码中的某一行异常，是没有上下文的，要深入得分析，就需要运行的上下文，对此，我们可以通过如下方式获取到实际运行flow，通过objdump，我们可以抓到完整的文件汇编信息，这里务必注意，so一定是要带symbols文件的，如果用strip的，有一些symbol信息就看不到了。

arm-linux-androideabi-objdump -dSl libandroid_servers.so > libandroid_servers.asm

．　反汇编之后，我们可以结合trace文件来分析上下文了，依旧需要回到trace文件中，我们关注到异常的trace中，挂了的pc是0x48224，因此在libanroid_servers.asm中，检索下这个数值，可以看到异常的位置以及更加细致的调用flow，在这里我们可以看到是com_android_server_tv_TvInputHal.cpp的436行（addOrUpdateStream中）调用如下flow发生异常。

　　通过如上flow，我们可以看到异常是在取*((uint32_t*)R0)的值时挂了，通过tombstone，可以明确R0的值是0x0061006e，也就是异常报错的那个错误值的来源了。也因此我们需要看下这个值是什么，到底怎么来的。

　　通过上面反汇编的代码，我们就可以开始分析相关flow了，R0的是*(（uint32_t*）R8+12)，
从tombstone中，我们也可以看到R8 buffer前后的内容，有时候可以辅助分析，其中红框部分是地址，绿框是buffer内容，蓝框是内容的ASCII换算后的字符，这里R8是cdf037f0，对应的*(（uint32_t*）R8+12）就是0xcdf037fc了(这里寄存器和对应的值对不上的原因是不是同个tombstone文件…）。我们这里的代码看到的是strongPointer里面的调用，比较的是mptr，也就是我们只能明确，这里异常的对象是sp对象，但具体是哪一个，我们还不能确定，因此，我们需要查下R8这个值是怎么来的，是什么元素？

　　实际上，通过如下一处比较跳转指令，可以判断r0是connection.mSourceHandle的值，而connection就是R8，

　　实际上，往上回溯，我们也可以分析到，R8记录的就是connection的值了，通过上面的分析，我们可以明确connection.mSourceHandle的值异常了，导致问题的发生，那方向就是查这个值异常的原因，最后查到是google bug来着，并发issue。

　　如上的分析是基于32bit的Android，对应toolchain用的也是32bit的，64bit的toolchain如下，source&&lunch之后即可调用。

32位
arm-linux-androideabi-objdump -dSl libxxx.so > libxxx.asm
arm-linux-androideabi-addr2line -f -e bin  -a 0x12345678
arm-linux-androideabi-gdb bin

64位：
aarch64-linux-android-objdump -dSl libxxx.so > libxxx.asm
aarch64-linux-android-addr2line -f -e bin -a 0x1111222233334444

https://blog.csdn.net/jscese/article/details/46547985　-> arm寄存器用途