如何分析NDK crash的堆栈信息

使用arm-eabi-addr2line工具跟踪Android调用堆栈
作者：liangshengyang
转自：http://www.linuxidc.com/Linux/2011-01/31803.htm

在通常的C/C++代码中，可以通过响应对内存操作不当引起的Segmentation Fault错误即信号SIGSEGV（11）做出响应处理。只要在程序中设置SIGSEGV的handler中，调用libc的backtrace，打出对应的堆栈信息，很快就能找到问题所在。但在Android中，bionic并不提供类似功能，而且log信息是走的loger，通过logcat才可以看到。但是android也会输出log信息，象下面这样：

02-08 10:36:32.076: INFO/DEBUG(1261): pid: 1959, tid: 1959  >>> Android.radio <<<
02-08 10:36:32.076: INFO/DEBUG(1261): signal 11 (SIGSEGV), fault addr 00198080
02-08 10:36:32.076: INFO/DEBUG(1261):  r0 00198080  r1 81116dac  r2 ffffffea  r3 00000000
02-08 10:36:32.086: INFO/DEBUG(1261):  r4 8111a9f0  r5 0000000a  r6 00000888  r7 0000000a
02-08 10:36:32.086: INFO/DEBUG(1261):  r8 735f6d66  r9 525f6474  10 4104bcd8  fp 00000000
02-08 10:36:32.086: INFO/DEBUG(1261):  ip a0000000  sp bec1a300  lr 81112561  pc 81109124  cpsr 80010010
02-08 10:36:32.306: INFO/DEBUG(1261):          #00  pc 00009124  /system/lib/libfmradio_jni.so
02-08 10:36:32.306: INFO/DEBUG(1261):          #01  pc 0001255c  /system/lib/libfmradio_jni.so
02-08 10:36:32.306: INFO/DEBUG(1261):          #02  pc 0000c93e  /system/lib/libfmradio_jni.so
02-08 10:36:32.316: INFO/DEBUG(1261):          #03  pc 0000ae14  /system/lib/libfmradio_jni.so
02-08 10:36:32.316: INFO/DEBUG(1261):          #04  pc 00008a72  /system/lib/libfmradio_jni.so
02-08 10:36:32.316: INFO/DEBUG(1261):          #05  pc 00006c22  /system/lib/libfmradio_jni.so
02-08 10:36:32.326: INFO/DEBUG(1261):          #06  pc 00004d92  /system/lib/libfmradio_jni.so
02-08 10:36:32.326: INFO/DEBUG(1261):          #07  pc 0000e434  /system/lib/libdvm.so

通常编译Android代码时，出于size的考虑，剔除了符号信息。但我们可以使用编译时生成的二进制文件(转注：含有符号信息的文件，通常位于./out/target/product/[PROJECT]/symbols/system/lib/目录)，获取其符号信息，从而得到调用堆栈：

$ ./prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-addr2line -f -e ./out/target/product/[PROJECT]/symbols/system/lib/libfmradio_jni.so 0000960c 000129ec 0000cdce 0000b2a4 00009496 00008258 000054f6
non_congruent
bionic/libc/arch-arm/bionic/memcpy.S:229
__sfvwrite
bionic/libc/stdio/fvwrite.c:151
__sprint
bionic/libc/stdio/vfprintf.c:71
printf
bionic/libc/stdio/printf.c:44
fm_std_Power
frameworks/base/fmradio/jni/../../../../external/.../fmradio/fmapi/fm_std_api.c:144
_Z11fm_SwitchOnv
frameworks/base/fmradio/jni/fm_functions.cpp:95
radio_SwitchOn
frameworks/base/fmradio/jni/native.cpp:41
yang@Ubuntu$ c++filt _Z11fm_SwitchOnv
fm_SwitchOn()

通过这种方式，即可得到调用堆栈信息，找出问题所在。

-------------------------------------------------------------------------------------------------------------------
方法二
-------------------------------------------------------------------------------------------------------------------
cat logcat_3.log | ndk-stack -sym ~/[SOURCE-DIR]/out/target/product/[PROJECT]/symbols/system/lib/


-------------------------------------------------------------------------------------------------------------------
方法三
-------------------------------------------------------------------------------------------------------------------

有两种方法可以分析 crash 的堆栈信息

1 google提供了一个python脚本，可以从 

http://code.google.com/p/android-ndk-stacktrace-analyzer/

 下载这个python脚本，然后使用 adb logcat -d > logfile 导出 crash 的log,
 使用 arm-eabi-objdump 位于build/prebuilt/linux-x86/arm-eabi-4.2.1/bin下面
 把so或exe转换成汇编代码，如：arm-eabi-objdump -S mylib.so > mylib.asm,
 使用脚本
python parse_stack.py <asm-file> <logcat-file>

2 直接使用NDK下面的  arm-eabi-addr2line

例如：arm-eabi-addr2line -C -f -e libxxx.so 0x#####(输出日志中最上面的pc值，可以回溯最终函数调用顺序)

android调试工具addr2line使用补充

使用addr2line追踪自有动态库(so文件)的bug, 补充:
解决出现 ??:0 , 没法展示源代码行数的问题

在Android.mk 文件中:

Java代码

1. LOCAL_CFLAGS := -D__STDC_CONSTANT_MACROS -Wl,-Map=test.map -g  

补充2个编译参数  -Wl,-Map=test.map -g .
增加gcc警告和调试标志

arm-linux-androideabi-addr2line -C -f -e /项目目录/obj/local/armeabi/libfaa_jni.so 0024362e

tip: 1,注意调试文件的位置在obj目录下,并非libs目录下生成的so文件
       2,0024362e 为出错的机制位置

还有：
在jni/目录下增加Application.mk 文件， 修改为debug 模式，进行调试 APP_OPTIM := debug
具体application.mk 文件的配置见： http://blog.csdn.net/weidawei0609/article/details/6561280

android调试　反汇编  

转：http://www.apkbus.com/forum.php?mod=viewthread&tid=577
在移植Android过程中会遇到很多Crash的情况，尤其是启动Android过程中。一般这些问题都可以通过看代码能解决，当然也有一些比较“妖娆”的问题，非常难找到头绪，在logcat日志也只会打印一些崩溃的堆栈，这些信息很难帮助我们定位问题。根据个人一个实例来介绍一下在Android移植过程中反汇编的用法。

       首先先看一下我遇到的一个logcat关于Crash的信息，我们来看看效果图：

 

       通过这个log信息我们可以看到libc.so崩溃了，再研究堆栈发现是libsqilte.so引起的，那么具体是哪一个函数崩溃了呢？这里面没有信息。另外内核加载动态库是动态加载的，就算我们反汇编出来libc.so和libsqlite.so，符号表也没有办法和log中地址对应上，除非我们能知道内核加载libc.so和libsqlite.so的基地址，这样我们就可以通过偏移找到相应的函数了。很幸运，Android确实规定了系统中的大部分库的内核加载地址。文件的位置在build/core下，有对应平台的map文件，比如：Arm平台文件名叫做prelink-linux-arm.map，Mips平台叫做prelink-linux-mips.map。我是在Mips平台出的问题，所以应该用prelink-linux-mips.map文件来定位。文件内容如下：
 




       从这个map文件我们可以查询到每个lib库的加载基地址。比如libc.so将会被内核加载到0x7EF00000，libsqlite.so加载到 0x7B100000。我们可以对照一下Crash的log信息也对应的上，说明这个文件在Android加载过程中起了作用。

       下一步我们需要反汇编libc.so和libsqlite.so。一般交叉编译器都提供了反汇编的工具，我的mips平台提供了mips-linux-gnu-objdump命令来进行反汇编。

Java代码：

1. mips-linux-gnu-objdump -dS libc.so > libc.dump
   
2. mips-linux-gnu-objdump -dS libsqlite.so > libsqlite.dump

复制代码

这样就可以得到libc和libsqlite的符号表。然后通过符号表，Android加载动态库的基地址，log信息就可以定位到那个函数出问题了，如果你对对应平台汇编语言熟悉的话可以阅读汇编代码找出问题。本文就不具体讲怎样利用这个三个文件信息了。有了这个三个文件，稍一研究就可以明白怎样分析了。

        一般情况下，Crash都不是Android源码的问题，最有可能的是内核有些模块没有编译进去。本例中就是和Mutex相关的模块没有编译进内核引起的问题。

        这些就是提供给我们的方法，在出现这样的事情的时候不要一下子全部删掉代码，也不要把项目给删掉。可以用用我们eoe提供的这个方法看看能不能给调试好。希望这个反汇编能给大家一些帮助。