Debug native code using addr2line on Android--再转一个Android(安卓).so 调试

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 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 forHistoryRecord{43d6cd48com.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  pc000527e8  /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.so000527e8
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

更多相关文章

随机推荐