Android NDK开发Crash错误定位[转]

使用 ndk-stack 的时候需要你的 lib 编译为 debug版的，通常需要下面的修改：

1. 修改 android.mk，增加，为 LOCAL_CFLAGS 增加 -g 选项
2. 修改 application.mk，增加 APP_OPTIM := debug
3. nkd-build -B
4. 从 obj/local/armeabi/ 下面把包复制到 libs/armeabi/
5. 出现异常后，调用 adb logcat | ndk-stack -sym libs/armeabi/

可以在链接的时候生成一个mapfile，总览整个代码的地址列表：

You need to generate a map file. The map file contains the function address and memory locations in your executable. Have your build system modified to generate a map file.

From the map file, you can use a text editor and search for addresses. I once wrote a program to find the two symbols bounding a given address. Worked great for environments like yours.

For android, I used the following line in the Application.mk or Android.mk (note that LOCAL_LDFLAGS is semi-undocumented in the Android NDK docs). LOCAL_LDFLAGS := -Wl,-Map,app.map

http://blog.csdn.net/xyang81/article/details/42319789

在Android开发中，程序Crash分三种情况：未捕获的异常、ANR（Application Not Responding）和闪退（NDK引发错误）。其中未捕获的异常根据logcat打印的堆栈信息很容易定位错误。ANR错 误也好查，Android规定，应用与用户进行交互时，如果5秒内没有响应用户的操作，则会引发ANR错误，并弹出一个系统提示框，让用户选择继续等待或 立即关闭程序。并会在/data/anr目录下生成一个traces.txt文件，记录系统产生anr异常的堆栈和线程信息。如果是闪退，这问题比较难查，通常是项目中用到了NDK引发某类致命的错误导致闪退。因 为NDK是使用C/C++来进行开发，熟悉C/C++的程序员都知道，指针和内存管理是最重要也是最容易出问题的地方，稍有不慎就会遇到诸如内存地址访问 错误、使用野针对、内存泄露、堆栈溢出、初始化错误、类型转换错误、数字除0等常见的问题，导致最后都是同一个结果：程序崩溃。不会像在Java层产生的 异常时弹出“xxx程序无响应，是否立即关闭”之类的提示框。当发生NDK错误后，logcat打印出来的那堆日志根据看不懂，更别想从日 志当中定位错误的根源，让我时常有点抓狂，火冒三丈，喝多少加多宝都不管用。当时尝试过在各个jni函数中打印日志来跟踪问题，那效率实在是太低了，而且 还定位不到问题。还好老天有眼，让我找到了NDK提供的几款调试工具，能够精确的定位到产生错误的根源。

NDK安装包中提供了三个调试工具：addr2line、objdump和ndk-stack，其中ndk-stack放在$NDK_HOME目录下， 与ndk-build同级目录。addr2line和objdump在ndk的交叉编译器工具链目录下，下面是我本机NDK交叉编译器工具链的目录结构：

从上图的目录结构中可以看出来，NDK针对不同的CPU架构实现了多套相同的工具。所以在选择addr2line 和objdump工具的时候，要根据你目标机器的CPU架构来选择。如果是arm架构，选择arm-linux-androidabi- 4.6/4.8（一般选择高版本）。x86架构，选择x86-4.6/4.8。mipsel架构，选择mipsel-linux-android-4.6 /4.8。如果不知道目标机器的CPU架构，把手机连上电脑，用adb shell cat /proc/cpuinfo可以查看手机的CPU信息。下图是我本机的arm架构工具链目录结构：

下面通过NDK自带的例子hello-jni项目来演示一下如何精确的定位错误

    - ::38.246: D/dalvikvm(): Late-enabling CheckJNI
    - ::38.246: I/ActivityManager():
    Start proc com.example.hellojni for activity com.example.hellojni/.HelloJni: pid= uid= gids={, , }
    - ::38.296: I/dalvikvm(): Enabling JNI app bug workarounds for target SDK version ...
    - ::38.366: D/dalvikvm(): Trying to load lib /data/app-lib/com.example.hellojni-/libhello-jni.so 0x422a4f58
    - ::38.366: D/dalvikvm(): Added shared lib /data/app-lib/com.example.hellojni-/libhello-jni.so 0x422a4f58
    - ::38.366: A/libc(): Fatal signal  (SIGFPE) at 0x0000513a (code=-), thread  (xample.hellojni)
    - ::38.476: I/DEBUG(): pid: , tid: , name: xample.hellojni  >>> com.example.hellojni <<<
    - ::38.476: I/DEBUG(): signal  (SIGFPE), code - (SI_TKILL), fault addr 0000513a
    - ::38.586: I/DEBUG():     r0   r1 0000513a  r2   r3
    - ::38.586: I/DEBUG():     r4   r5 0000000d  r6 0000513a  r7 0000010c
    - ::38.586: I/DEBUG():     r8 75226d08  r9   sl 417c5c38  fp bedbf134
    - ::38.586: I/DEBUG():     ip   sp bedbf0f0  lr 4012e169  pc 4013d10c  cpsr 000f0010
                                                // 省略部份日志 。。。。。。
    - ::38.596: I/DEBUG(): backtrace:
    - ::38.596: I/DEBUG():     #  pc 0002210c  /system/lib/libc.so (tgkill+)
    - ::38.596: I/DEBUG():     #  pc   /system/lib/libc.so (pthread_kill+)
    - ::38.596: I/DEBUG():     #  pc   /system/lib/libc.so (raise+)
    - ::38.596: I/DEBUG():     #  pc 00000e80  /data/app-lib/com.example.hellojni-/libhello-jni.so (__aeabi_idiv0+)
    - ::38.596: I/DEBUG():     #  pc 00000cf4  /data/app-lib/com.example.hellojni-/libhello-jni.so (willCrash+)
    - ::38.596: I/DEBUG():     #  pc 00000d1c  /data/app-lib/com.example.hellojni-/libhello-jni.so (JNI_OnLoad+)
    - ::38.596: I/DEBUG():     #  pc 00052eb1  /system/lib/libdvm.so (dvmLoadNativeCode(char const*, Object*, char**)+)
    - ::38.596: I/DEBUG():     #  pc 0006a62d  /system/lib/libdvm.so
    - ::38.596: I/DEBUG():          // 省略部份日志 。。。。。。
    - ::38.596: I/DEBUG(): stack:
    - ::38.596: I/DEBUG():          bedbf0b0  71b17034  /system/lib/libsechook.so
    - ::38.596: I/DEBUG():          bedbf0b4  7521ce28
    - ::38.596: I/DEBUG():          bedbf0b8  71b17030  /system/lib/libsechook.so
    - ::38.596: I/DEBUG():          bedbf0bc  4012c3cf  /system/lib/libc.so (dlfree+)
    - ::38.596: I/DEBUG():          bedbf0c0    /system/lib/libc.so
    - ::38.596: I/DEBUG():          // 省略部份日志 。。。。。。
    - ::38.736: W/ActivityManager():   Force finishing activity com.example.hellojni/.HelloJni  

日志分析：

第 3行开始启动应用，第5行尝试加载应用数据目录下的so，第6行在加载so文件的时候产生了一个致命的错误，第7行的Fatal signal 8提示这是一个致命的错误，这个信号是由linux内核发出来的，信号8的意思是浮点数运算异常，应该是在willCrash函数中做除0操作所产生的。 下面重点看第15行backtrace的日志，backtrace日志可以看作是JNI调用的堆栈信息，以“#两位数字 pc”开头的都是backtrace日志。注意看第20行和21行，是我们自己编译的so文件和定义的两个函数，在这里引发了异常，导致程序崩溃。

- ::38.596: I/DEBUG():     #  pc 00000cf4  /data/app-lib/com.example.hellojni-/libhello-jni.so (willCrash+)
- ::38.596: I/DEBUG():     #  pc 00000d1c  /data/app-lib/com.example.hellojni-/libhello-jni.so (JNI_OnLoad+)

开始有些眉目了，但具体崩在这两个函数的哪个位置，我们是不确定的，如果函数代码比较少还好查，如果比较复杂的话，查起来也费劲。这时候就需要靠NDK为我们提供的工具来精确定位了。在这之前，我们先记录下让程序崩溃的汇编指令地址，willCrash：00000cf4，JNI_OnLoad：00000d1c

方式1：使用arm-linux-androideabi-addr2line  定位出错位置
以arm架构的CPU为例，执行如下命令：

/Users/yangxin/Documents/devToos/java/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-addr2line -e /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/obj/local/armeabi-v7a/libhello-jni.so 00000cf4 00000d1c 

-e：指定so文件路径

0000cf4 0000d1c：出错的汇编指令地址

结果如下：

是不是惊喜的看到我们想要的结果了，分别在hello-jni.c的10和15行的出的错，再回去看看hello-jni.c的源码，15行的Jni_OnLoad函内调用了willCrash函数，第10行做了除0的操作引发的crash。

方式2：使用arm-linux-androideabi-objdump  定位出错的函数信息

在第一种方式中，通过addr2lin已经获取到了代码出错的位置，但是不知道函数的上下文信息，显得有点不是那么的“完美”，对于追求极致的我来说，这显然是不够的，下面我们来看一下怎么来定位函数的信息。
首先使用如下命令导出so的函数表信息：

/Users/yangxin/Documents/devToos/java/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-objdump -S -D /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/obj/local/armeabi-v7a/libhello-jni.so > Users/yangxin/Desktop/dump.log

在生成的asm文件中，找出我们开始定位到的那两个出错的汇编指令地址（在文件中搜索cf4或willCrash可以找到），如下图所示：

通过这种方式，也可以查出这两个出错的指针地址分别位于哪个函数中。

方式3：ndk-stack

如果你觉得上面的方法太麻烦的话，ndk-stack可以帮你减轻操作步聚，直接定位到代码出错的位置。

adb logcat | ndk-stack -sym /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/obj/local/armeabi-v7a  

当程序发生crash时，会输出如下信息：

    pid: , tid: , name: xample.hellojni  >>> com.example.hellojni <<<
    signal  (SIGFPE), code - (SI_TKILL), fault addr 0000587e
    Stack frame #  pc 0002210c  /system/lib/libc.so (tgkill+)
    Stack frame #  pc   /system/lib/libc.so (pthread_kill+)
    Stack frame #  pc   /system/lib/libc.so (raise+)
    Stack frame #  pc 00000e80  /data/app-lib/com.example.hellojni-/libhello-jni.so (__aeabi_idiv0+): Routine __aeabi_idiv0 at /s/ndk-toolchain/src/build/../gcc/gcc-4.6/libgcc/../gcc/config/arm/lib1funcs.asm:
    Stack frame #  pc 00000cf4  /data/app-lib/com.example.hellojni-/libhello-jni.so (willCrash+): Routine willCrash at /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/jni/hello-jni.c:
    Stack frame #  pc 00000d1c  /data/app-lib/com.example.hellojni-/libhello-jni.so (JNI_OnLoad+): Routine JNI_OnLoad at /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/jni/hello-jni.c:
    Stack frame #  pc 00052eb1  /system/lib/libdvm.so (dvmLoadNativeCode(char const*, Object*, char**)+)
    Stack frame #  pc 0006a62d  /system/lib/libdvm.so  

第7行和第8行分别打印出了在源文件中出错的位置，和addr2line得到的结果一样。

1. adb logcat > crash.log
2. ndk-stack -sym /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/obj/local/armeabi-v7a -dump crash.log

得到的结果和上面的方式是一样的。