Debug native code using addr2line on Android

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.csdn.net/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 0000000108-22 23:27:40.730: INFO/DEBUG(65): r0 00000001 r1 00000000 r2 afd438e4 r3 0000000108-22 23:27:40.730: INFO/DEBUG(65): r4 4825395c r5 00001000 r6 00001000 r7 0000000108-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 000000000000000008-22 23:27:40.730: INFO/DEBUG(65): scr 8000001208-22 23:27:40.790: INFO/DEBUG(65): #00 pc 00018656 /data/data/com.test/lib/libmylib.so08-22 23:27:40.790: INFO/DEBUG(65): #01 pc 000186d2 /data/data/com.test/lib/libmylib.so08-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 命令的使用

关于调试：调试中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 26ba7eecr1 403f3c49r2 e98cf6f4r3 405e58ae
I/DEBUG ( 3411):r4 00000000r5 00000000r6 4229b6ccr7 48fecec8
I/DEBUG ( 3411):r8 490ecd84r9 48feceb410 48fece9cfp 00314d30
I/DEBUG ( 3411):ip ad3527cdsp 490ecd68lr ad3527ebpc 00000000cpsr 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): #00pc 00000000
I/DEBUG ( 3411): #01pc 000527e8/system/lib/libandroid_runtime.so
I/DEBUG ( 3411): #02pc 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): 490ecd2800000013
I/DEBUG ( 3411): 490ecd2cad05f661/system/lib/libdvm.so
I/DEBUG ( 3411): 490ecd30410c2aec/dalvik-LinearAlloc (deleted)
I/DEBUG ( 3411): 490ecd34ad0560f7/system/lib/libdvm.so
I/DEBUG ( 3411): 490ecd38400292d8/mspace/dalvik-heap/zygote/0 (deleted)
I/DEBUG ( 3411): 490ecd3c410c2aec/dalvik-LinearAlloc (deleted)
I/DEBUG ( 3411): 490ecd40000003dc
I/DEBUG ( 3411): 490ecd44ad0591f5/system/lib/libdvm.so
I/DEBUG ( 3411): 490ecd4842200d44/data/dalvik-cache/system@@classes.dex
I/DEBUG ( 3411): 490ecd4c42200d44/data/dalvik-cache/system@@classes.dex
I/DEBUG ( 3411): 490ecd504232b87d/data/dalvik-cache/system@@classes.dex
I/DEBUG ( 3411): 490ecd5400000000
I/DEBUG ( 3411): 490ecd584264aa04/data/dalvik-cache/system@@classes.dex
I/DEBUG ( 3411): 490ecd5c410c1cbc/dalvik-LinearAlloc (deleted)
I/DEBUG ( 3411): 490ecd60df002777
I/DEBUG ( 3411): 490ecd64e3a070ad
I/DEBUG ( 3411): #01 490ecd6843160000
I/DEBUG ( 3411): 490ecd6cad05f661/system/lib/libdvm.so
I/DEBUG ( 3411): 490ecd70490ecda8
I/DEBUG ( 3411): 490ecd74ad00f1f8/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指针为空，这就是问题之所在，接下来就是要定位这个问题，上边说了，这里是程序执行时的栈，那么#01pc 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

更多相关文章

随机推荐