前几天遇到一个ndk崩溃，只有crash日志，没有存当时编译的.o文件。有效信息如下：
从这个信息中可以知道最后崩溃在了一个叫做 parseCommonGameOver的方法里面，具体崩溃位置在相对函数地址偏移 1349（注意这个是10进制）的位置。网上各种查资料，都需要.cpp文件对应的当时编译的.o文件才可以用。我想了想，如果代码没有什么变化，那么生成出来的.o文件也不会有什么变化。于是拿了个出包时间相近的时间生成的.o文件，利用objdump工具进行反汇编，定位到大致出错的具体行数。
总结一下步骤：
1，通过崩溃的ndk日志确定崩溃大致位置及具体偏移地址。
2，确定当时编译的环境：ndk版本，toolchains版本（Application.mk中查看），对应的abi，想办法弄到当时cpp编译出的.o文件（通过svn及出包的时间拿到当时的cpp，临时编译出.o文件也可以）
3，利用对应的 objdump 工具使用 objdump -S .opath > asmfilepath 命令拿到对应的汇编代码。比如我们的包是在windows下面使用 ndk-r10d 下面的 arm-linux-androideabi-4.9 打包的，那么我使用的命令就是：
<basepath>/android-ndk-r10d/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/arm-linux-androideabi-objdump.exe -S myobj.o > myobj.asm
4，拿到这个 myobj.asm （后缀不重要！.txt也可以）文件后，找到对应的函数名，将崩溃日志中的10进制偏移转化为16进制偏移然后到里面去找具体崩溃日志。因为不一定对应得上（比如我遇到的就是cpp与.o文件没有一一对应的），所以要靠自己确定大致崩溃行数再结合代码查看。
其实我上面这份崩溃日志中有告诉我崩溃原因： Cause: null pointer dereference，但我看源码只看到隐患，并且这个崩溃出现机率很小，所以需要通过上面这些步骤定位到具体代码块。
留这个笔记，也希望可以帮到路过的朋友。