Android定位crash

采用调用链或者函数符号表来定位crash位置

android 应用程序开发及调试过程中&＃xff0c;单步调试仍然不是很方便。由于依托java层&＃xff0c;jni层的源代码要以动态库形式装载。

但是好在程序crash时&＃xff0c;log中会抛出断点信息。

**********************************************************************************************

补充断点信息

02-10 20:47:54.126: I/DEBUG(2370): Build fingerprint: &＃39;samsung/SCH-iXXXX/SCH-iXXXXX/SCH-iXXXX:2.XXX/FROYO/ED29:user/release-keys&＃39;
02-10 20:47:54.126: I/DEBUG(2370): pid: 4398, tid: 4402  >>> /system/bin/mediaserver <<<
02-10 20:47:54.126: I/DEBUG(2370): signal 11 (SIGSEGV), fault addr deadbaad
02-10 20:47:54.126: I/DEBUG(2370):  r0 00000000  r1 afd14921  r2 00000027  r3 00000070
02-10 20:47:54.126: I/DEBUG(2370):  r4 afd42328  r5 00000000  r6 00000000  r7 ffffee07
02-10 20:47:54.126: I/DEBUG(2370):  r8 00100000  r9 a811c479  10 4031f000  fp 0002cef8
02-10 20:47:54.126: I/DEBUG(2370):  ip 00001730  sp 4041e8b0  lr deadbaad  pc afd11f74  cpsr 60000030
02-10 20:47:54.126: I/DEBUG(2370):  d0  643a64696f72646e  d1  6472656767756265
02-10 20:47:54.126: I/DEBUG(2370):  d2  6f6365446d28203d  d3  6874646957646564
02-10 20:47:54.126: I/DEBUG(2370):  d4  6f63726f6c6f632f  d5  6e6f69737265766e

02-10 20:47:54.227: I/DEBUG(2370):          #00  pc 00011f74  /system/lib/libc.so
02-10 20:47:54.227: I/DEBUG(2370):          #01  pc 0000138e  /system/lib/liblog.so
02-10 20:47:54.227: I/DEBUG(2370):          #02  pc 000013f0  /system/lib/libjin-1.so
02-10 20:47:54.227: I/DEBUG(2370):          #03  pc 00001522  /system/lib/libjni-2.so
02-10 20:47:54.231: I/DEBUG(2370):          #04  pc 00008e1c  /system/lib/libxxxxxxx.so
02-10 20:47:54.231: I/DEBUG(2370):          #05  pc 0003920c  /system/lib/libmedia.so

**********************************************************************************************

此时要注意&＃xff0c;不要找系统库的问题&＃xff0c;要找就找你自己编译的库。 像#02,#03的。

此时定位库的出问题的函数的位置一般只能依靠两种方法。假若动态库为jni-1.so&＃xff0c;jni-2.so

方法1&＃xff0c;若库在编译时为NO_DEBUG版本&＃xff0c;即不含有DEBUG信息&＃xff08;NDK_DEBUG&＃61;0&＃xff09;&＃xff0c;这种情况下&＃xff0c;可以用

obj-dump -T  jni-1.so

obj-dump -T jni-2.so

的方法&＃xff0c;将函数符号表打印出来&＃xff0c;这样可以得到每个函数的入口地址。

结合log 中的crash信息&＃xff0c;我们可以粗略定位&＃xff0c;问题出在哪个函数里面。

但是这种方法找不到精确的出问题的位置&＃xff0c;有时候函数比较长时&＃xff0c;在函数里面进一步判断出问题的地方也比较麻烦。

此时可采用第二种方法

方法2&＃xff0c;编译库的时候&＃xff0c;采用DEBUG版本&＃xff0c;即含有DEBUG信息&＃xff08;NDK_DEBUG&＃61;1&＃xff09;&＃xff0c;这种情况下。

我们可以把crash的信息复制下来&＃xff0c;放在记事本里面&＃xff0c;命名为crash.log.txt&＃xff0c;将此记事本放在android工程的libs/armeabi/目录下,当然也可以是libs/armeabi-v7a

/cygdrive/e/Software/android-ndk-r6b/ndk-stack -sym obj/local/armeabi-v7a/ -dump e:/logs/crash.log.txt
中间一项也可以是  -sym libs/armeabi-v7a/ 反正就是你的动态库的位置。

这样会打印出具体的出问题的代码位置&＃xff0c;这样一般可以精确到行。