本文介绍 Android 中 tombstone 文件的作用及如何通过 tombstone 和 addr2line 工具定位崩溃问题，帮助开发者理解 native 层面的堆栈跟踪。
http://www.codexperiments.com/android/2010/08/tips-tricks-debugging-android-ndk-stack-traces/
http://crazydaks.com/debugging-in-android-with-tombstones.html
http://blog.youkuaiyun.com/coder_jack/archive/2010/06/28/5700348.aspx
- Debugging in Android with Tombstones
Everytime a process crashes under Android, a so called Tombstone is written for the process. A tombstone is a file containing important information about the process when it crashed. A slimmed core dump of sorts.
It is printed out in the log (can be seen in the printout using adb shell logcat), but the tombstones are also saved and stored on target under /data/tombstones/ and are called tombstone_XX where XX is a number increased by one with each crash.
To get a stacktrace for the crashed process containing file and line information we need to cross reference
the tombstone with the debugging symbols located on the host. generally the debug symbols are stripped when the libraries are loaded in the rootfs to save space. Hence you may need to dig the appropriate /out/product/xxx/symbols/system/libxx to get the unstripped libraries. Once that you can extract the line number and function name etc from a uitility called addr2line. this is generally found in the prebuilt directory of android source distribution. $(android-root)prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin is the normal location.
hence once you have located the unstripped libraries and location of addr2line tool on your host its as simple as using the addr2line command.
$(android-root)prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/addr2line -f -e /out/product/xxx/symbols/system/libc.so 0xbe8c1630 if 0xbe8c1630 is one of the symbols in the strack trace from library libc.so. is a typical dump for a system that underwent 6 crashes on my target.
# ls -l /data/tombstones
-rw——- system system 24216 2000-01-01 00:04 tombstone_02
-rw——- system system 22684 2000-01-01 00:03 tombstone_01
-rw——- system system 21913 2000-01-01 00:02 tombstone_06
-rw——- system system 24216 2000-01-01 00:04 tombstone_03
-rw——- system system 24322 2000-01-01 00:10 tombstone_05
-rw——- system system 22612 2000-01-01 00:02 tombstone_04
-rw——- system system 24665 2000-01-01 00:02 tombstone_00
# cat tombstone_01
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: ‘generic/myboard_xxx/xxx/myplatform:2.1/ERD79/eng.arunks.20100726.14330
8:eng/test-keys’
pid: 1138, tid: 1138 >>> /system/bin/bluetoothd <<<
signal 11 (SIGSEGV), fault addr deadbaad
r0 00000000 r1 afe13369 r2 00000027 r3 00000054
r4 afe3ae08 r5 00000000 r6 00000000 r7 0000a000
r8 00000000 r9 00000000 10 00000000 fp 00000000
ip 00002ed8 sp bec782d8 lr deadbaad pc afe10a20 cpsr 60000030
#00 pc 00010a20 /system/lib/libc.so
#01 pc 0000b332 /system/lib/libc.so
#02 pc 0000ca62 /system/lib/bluez-plugin/audio.so
#03 pc 0000d1ce /system/lib/bluez-plugin/audio.so
#04 pc 0000e0ba /system/lib/bluez-plugin/audio.so
#05 pc 0002f9a2 /system/lib/libbluetoothd.so
#06 pc 00026806 /system/lib/libbluetoothd.so
#07 pc 00026986 /system/lib/libbluetoothd.so
#08 pc 0002800c /system/lib/libbluetoothd.so
#09 pc 00028b72 /system/lib/libbluetoothd.so
#10 pc 0001891a /system/lib/libbluetoothd.so
#11 pc 0000c228 /system/lib/libc.so
code around pc:
afe10a10 f8442001 4798000c e054f8df 26002227
afe10a20 2000f88e ef2cf7fb f7fd2106 f04fe80a
afe10a30 91035180 460aa901 96012006 f7fc9602
code around lr:
deadba9c ffffffff ffffffff ffffffff ffffffff
deadbaac ffffffff ffffffff ffffffff ffffffff
deadbabc ffffffff ffffffff ffffffff ffffffff
stack:
bec78298 bec78334 [stack]
bec7829c bec7838b [stack]
bec782a0 afe3b02c /system/lib/libc.so
is a typical tombstone dump from my system….
- Tips & Tricks: Debugging with Android NDK stack traces
Stuck in the hell of crashing applications? Don’t know how to find the tiny allocation or deallocation mistake hidden in a code stack of thousands of lines? Here is your way to heaven.
08-22 23:27:40.730: INFO/DEBUG(65): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 08-22 23:27:40.730: INFO/DEBUG(65): Build fingerprint: 'htc_wwe/htc_bravo/bravo/bravo:2.2/FRF91/218634:user/release-keys' 08-22 23:27:40.730: INFO/DEBUG(65): pid: 2474, tid: 2485 >>> com.test <<< 08-22 23:27:40.730: INFO/DEBUG(65): signal 11 (SIGSEGV), fault addr 00000001 08-22 23:27:40.730: INFO/DEBUG(65): r0 00000001 r1 00000000 r2 afd438e4 r3 00000001 08-22 23:27:40.730: INFO/DEBUG(65): r4 4825395c r5 00001000 r6 00001000 r7 00000001 08-22 23:27:40.730: INFO/DEBUG(65): r8 48253ad8 r9 432faf40 10 802a3448 fp 432faf40 ... 08-22 23:27:40.730: INFO/DEBUG(65): d30 0000000000000000 d31 0000000000000000 08-22 23:27:40.730: INFO/DEBUG(65): scr 80000012 08-22 23:27:40.790: INFO/DEBUG(65): #00 pc 00018656 /data/data/com.test/lib/libmylib.so 08-22 23:27:40.790: INFO/DEBUG(65): #01 pc 000186d2 /data/data/com.test/lib/libmylib.so 08-22 23:27:40.790: INFO/DEBUG(65): #02 pc 00018708 /data/data/com.test/lib/libmylib.so ...
Well if you understand that, then it means that either you’re an overly talented developer or you’d rather look for an ophthalmologist 
. But you’re just a normal coder, than at best you know that this is a stack trace. An Android native stack trace to be more precise, generated after an application crash.
Hopefully, some tools are available to “decrypt” that mysterious data: arm-eabi-addr2line. This tools is in the “${ANDROID_NDK}/build/prebuilt/linux-x86/arm-eabi-[version]/bin/ ” directory which contains some utility tools for ARM processors. And combine with the original library that generated it, you can find the incriminated methods and file lines. And that’s priceless when you can’t debug your code!
First ensure your native code is compiled in Debug mode to access code information (“APP_OPTIM := debug ” in your application.mk). Then call the executable with your .so compiled library, for example:
${Android-NDK}/build/prebuilt/linux-x86/arm-eabi-[version]/bin/arm-eabi-addr2line -C -f -e libmylib.so
Then just type the address, the one you can find after the “pc ” directive, for example:
00018656
taken from line “#00 pc 00018656 /system/lib/libstlport.so “.
That’s all!
- android 调试中 addr2line 命令的使用
问题引出：i850的wifi定位开启后，在使用goole maps时出现rootfs重启现象，打印的log信息如下：
／／／／／／／／／／／／／／／／／／／／／／／／／／
I/DEBUG ( 3411): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 3411): Build fingerprint: 'PROWAVE/i850/i850/:Eclair/ECLAIR/eng.zhangjiejing.20100430.113200:eng/test-keys'
I/DEBUG ( 3411): pid: 3436, tid: 3475 >>> system_server <<<
I/DEBUG ( 3411): signal 11 (SIGSEGV), fault addr 00000000
I/DEBUG ( 3411): r0 26ba7eec r1 403f3c49 r2 e98cf6f4 r3 405e58ae
I/DEBUG ( 3411): r4 00000000 r5 00000000 r6 4229b6cc r7 48fecec8
I/DEBUG ( 3411): r8 490ecd84 r9 48feceb4 10 48fece9c fp 00314d30
I/DEBUG ( 3411): ip ad3527cd sp 490ecd68 lr ad3527eb pc 00000000 cpsr 00000010
I//system/bin/dhcpcd( 3673): wlan0: looping
I//system/bin/dhcpcd( 3673): wlan0: signal_fd: 4,fd:5
I/ActivityManager( 3436): Starting activity: Intent { act=android.intent.action.MAIN cat=[android.intent.category.HOME] flg=0x10200000 cmp=com.android.launcher/.Launcher }
D/LocationManager( 3777): removeUpdates: listener = P.a@43da64b8
I/DEBUG ( 3411): #00 pc 00000000
I/DEBUG ( 3411): #01 pc 000527e8 /system/lib/libandroid_runtime.so
I/DEBUG ( 3411): #02 pc 0000f1f4 /system/lib/libdvm.so
I/DEBUG ( 3411):
I/DEBUG ( 3411): code around lr:
I/DEBUG ( 3411): ad3527d8 69e19806 694c9000 1c191c10 9b059a04
I/DEBUG ( 3411): ad3527e8 b00247a0 46c0bd10 00017868 00006728
I/DEBUG ( 3411): ad3527f8 4c0fb570 447c4d0f 6b2e1965 d1112e00
I/DEBUG ( 3411):
I/DEBUG ( 3411): stack:
I/DEBUG ( 3411): 490ecd28 00000013
I/DEBUG ( 3411): 490ecd2c ad05f661 /system/lib/libdvm.so
I/DEBUG ( 3411): 490ecd30 410c2aec /dalvik-LinearAlloc (deleted)
I/DEBUG ( 3411): 490ecd34 ad0560f7 /system/lib/libdvm.so
I/DEBUG ( 3411): 490ecd38 400292d8 /mspace/dalvik-heap/zygote/0 (deleted)
I/DEBUG ( 3411): 490ecd3c 410c2aec /dalvik-LinearAlloc (deleted)
I/DEBUG ( 3411): 490ecd40 000003dc
I/DEBUG ( 3411): 490ecd44 ad0591f5 /system/lib/libdvm.so
I/DEBUG ( 3411): 490ecd48 42200d44 /data/dalvik-cache/system@@classes.dex
I/DEBUG ( 3411): 490ecd4c 42200d44 /data/dalvik-cache/system@@classes.dex
I/DEBUG ( 3411): 490ecd50 4232b87d /data/dalvik-cache/system@@classes.dex
I/DEBUG ( 3411): 490ecd54 00000000
I/DEBUG ( 3411): 490ecd58 4264aa04 /data/dalvik-cache/system@@classes.dex
I/DEBUG ( 3411): 490ecd5c 410c1cbc /dalvik-LinearAlloc (deleted)
I/DEBUG ( 3411): 490ecd60 df002777
I/DEBUG ( 3411): 490ecd64 e3a070ad
I/DEBUG ( 3411): #01 490ecd68 43160000
I/DEBUG ( 3411): 490ecd6c ad05f661 /system/lib/libdvm.so
I/DEBUG ( 3411): 490ecd70 490ecda8
I/DEBUG ( 3411): 490ecd74 ad00f1f8 /system/lib/libdvm.so
W/ActivityManager( 3436): Activity pause timeout for HistoryRecord{43d6cd48 com.google.android.apps.maps/com.google.android.maps.MapsActivity}
wait for fb sleep Enter
D/WifiService( 3436): releaseWifiLockLocked: WifiLock{NetworkLocationProvider type=2 binder=android.os.Binder@43bfb998}
binder: release 3436:3560 transaction 22233 in, still active
binder: send failed reply for transaction 22233 to 3777:3777
I/DEBUG ( 3411): debuggerd committing suicide to free the zombie!
I/DEBUG ( 3855): debuggerd: Apr 14 2010 14:24:22
I/ServiceManager( 2066): service 'usagestats' died
I/ServiceManager( 2066): service 'account' died
／／／／／／／／／／／／／／／／／／／／／／／／／／
注意到红色部分，这就是程序执 行时的栈！显然第一个pc指针的值为0，也就是pc指针为空，这就是问题之所在，接 下来就是要定位这个问题，上边说了，这里是程序执行时的栈，那么#01 pc 000527e8 /system/lib/libandroid_runtime.so 这个地址就是我们要找的问题的范围，因为显然是后者先入栈的，所以显然前者包含于后者，那么通过如下命令用地址定位一下源码的位置：
cpp@cpp:~/r7_0422$ ../gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-addr2line -e out/target/product/i850/symbols /system/lib/libandroid_runtime.so 000527e8
frameworks/base/core/jni/android_location_GpsLocationProvider.cpp:397
cpp@cpp:~/r7_0422$
看到源码的397行是一个函数，那么000527e8就是这个函数的入 口地址了。继而，pc 000000 对应的调用就应该在该函数内部，看到该函数内部只是做了对另一个函数指针的调用而已，所以我们可以断定这个函数指针的值为空，显然调用一个空的指针函数是 错误的。所以需要给这个函数指针在早些时候赋值一下问题就可以解决了！
关于addr2line的一点补充： 如果可执行文件中没有包括调试符号，您将获得??:0 作为响应。 还有在linux中的readelf命令可以读取可执行文件的相关信息，比如有一个可执行文件 aa.elf 则可以这么使用： readelf -h aa.elf 参数－h读取可执行文件的head信息。
参考连接：http://www.xxlinux.com /linux/article/accidence/technique/20070125/7209.html
扫一扫
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
