ndk crash分析

        目前我所接触的android产品或项目，都是采用Java/JNI/C++的形式组织的。引擎或者数据处理的逻辑会通过C/C++处理，然后通过JNI封装，提供给Android UI(Java)调用。很多crash会发生在ndk这一层，crash后，logcat会疯狂的输出一堆信息，看着让人头疼，其实细看，还是能看出不少猫腻的。

    下面我就结合自身情况，简单介绍下如何给crash增加更多有用的输出信息或在crash之后我们该如何定位!

工作环境:

JDK 版本:   1.6(64bit)

ANDROID  SDK 版本:  4.2.2(64bit)

NDK 版本:  r9(64bit)

 

l  crash模块、线程定位:

         现在的软件，大多都是众多模块的封装、拼接，非一人之力能够完成。模块越多、越复杂，出现问题的可能性就越大。可能单个模块运行都ok，整个产品release、run，crash了，这很正常，相信很多朋友都遇到过。

   仔细观察logcat crash日志，会发现，一旦crash，会输出crash的pid、tid、以及thread name，其实这个thread name可以帮助非常明确的定位模块，后面是谁的问题就该谁去处理了。

         Linux下设置线程名称从kernel 2.6.9就开始支持了，prctl(…),自行google去怎么用。

Eg:

l  crash code定位：

 

方式一:

arm-linux-androideabi-addr2line.exe  C  -f  -e  libxxx.so   0x#####

说明:

1.       arm-linux-androideabi-addr2line.exe位置: ndk安装路径下toolchains目录下

2.       执行该命令的当前目录位置: 以libhello.so为例，当前执行命令的目录必须在jni/../obj/local/armeabi目录下，在jni/../libs/目录下好像不行。

3.       0x#####的选取: crash log中，backtrace下面的第一个pc的值。

Eg:

说明crash的代码位于hello.c第32行。

 

方式二:

       

parse_stack.py   asm_code crash_log

说明:

1.       parse_stack.py(https://code.google.com/p/android-ndk-stacktrace-analyzer/),google 提供的一个python脚本.

2.       asm_code 生成方式: arm-linux-androideabi-objdump.exe–S libxxx.so > xxx.asm

3.       crash_log的获取途径: 直接把logcat里面爆的crash保存起来即可。

Eg:

如果有更好的办法欢迎提出来，让crash不在那么畏惧。