应用稳定性优化2：Crash/Tombstone问题分析及定位

1. Crash/Tombstone问题原因分析

在这里插入图片描述

2. Tombstone问题定位方法

本节主要讲解Tombstone问题的分析定位方法。

2.1 信号量分析法

信号机制是进程之间相互传递消息的一种方法，下表展示的是一些常见的信号种类。
在这里插入图片描述

SIGBUS与SIGSEGV的区别

SIGBUS(Bus error)意味着指针所对应的地址是有效地址，但总线不能正常使用该指针。通常是未对齐的数据访问所致。比如int型要4字节对齐，short型的2字节对齐。例如：short array[16];int * p = (int *)&array[1];*p = 1；SIGSEGV(Segment fault)意味着指针所对应的地址是无效地址，没有物理内存对应该地址。例如：int pi= (int)0x00001111;*pi = 17。

2.2 反编译调用栈法

反编译调用栈步骤
在这里插入图片描述

新建一个tombstone.txt，把backtrace里面的内容写入到txt里面去；
执行脚本 ./panic.py tombstone.txt>log.txt；
更细致的调用栈可以参考stack里面的纪录；
打开log.txt之后，分析函数的调用栈，从调用栈找出逻辑关系。

虚拟机调用流程

反编译了调用栈之后，一般中间都有很多的虚拟机调用，这部分的顺序一般都是相同的，了解这些虚拟机函数，也有助于我们分析问题。下图是主要的虚拟机函数：
在这里插入图片描述

案例分析

进入某应用就崩溃，调用栈如下：
在这里插入图片描述

分析上方调用栈发现，因为调用dvmInterpret方法，表明启动Dalvik虚拟机解释器，并且解释执行指定的JAVA代码。
在这里插入图片描述

通过分析上方调用栈可以看到，因为调用dvmCallJNIMethod方法，表明是在native侧触发错误。

接着往下看，真正的原因在下方调用栈：
在这里插入图片描述

一个JAVA方法通过JNI调用底层方法时，传入一个非法的String，JNI在把这个String转换成char数组时导致失败。

2.3 地址分析法

Linux程序在运行时，会将所有用到的模块加载到内存，所有的段分布到统一的虚拟内存空间中，程序调用过程中的地址都是内存空间的虚拟地址，我们只知道该位置位于哪个模块，却不知道具体哪个函数出了问题。而地址的确对应了一个函数，因此只有知道了模块在内存中的分布情况，才能找到对应偏移位置的函数。

取得进程pid的内存分布

问题发生时，都会打印出当前的进程号。假如进程号为2429，命令如下(需要root) : adbshell cat /proc/2429/maps>2429.txt，然后我们把fault addr， stack地址放到2429.txt里面查找。一般fault addr在栈区，是栈溢出；在堆区，一般是数组越界或者内存被踩；在代码区，一般是函数指针跑飞了。

maps地址解析

其中，[stack]表示代表栈区；(deleted)表示堆区，内存可回收；一些.so,.jar,.dex,.apk表示代码区。

深入分析栈地址

backtrace和stack:里面都是栈的调用信息。backtrace里面地址我们可以用脚本panic.py去反编译。那stack：里面的地址如何分析呢？stack里面的地址是等于基地址+偏移地址，可以借用工具arm-linux-androideabi-objdump。Objdump一下libandroid_runtime.so，如下：
在这里插入图片描述