Using the Arm-eabi-addr2line tool to track the Android call stack
Author: Liangshengyang
Turn from: http://www.linuxidc.com/Linux/2011-01/31803.htm
In the usual C + + code, response can be made by responding to segmentation fault errors caused by improper memory operation, namely Signal SIGSEGV (11). As long as you set the SIGSEGV in the program handler, call the libc backtrace, play the corresponding stack information, you can quickly find the problem. But in Android, Bionic does not provide similar functionality, and log information is Loger, which can be seen through Logcat. But Android will also output log information, as follows:
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 (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-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
Typically, when you compile your Android code, you strip out symbolic information for size reasons. But we can use a compile-time binary file (note: A file with symbolic information, usually located in the./out/target/product/[project]/symbols/system/lib/directory), get its symbolic information, and get the call stack:
$./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 ()
In this way, you can get the call stack information to find out where the problem lies.
--------------------------------------------------------------------------------------------------------------- ----
Method Two
--------------------------------------------------------------------------------------------------------------- ----
Cat Logcat_3.log | Ndk-stack-sym ~/[source-dir]/out/target/product/[project]/symbols/system/lib/
--------------------------------------------------------------------------------------------------------------- ----
Method Three
--------------------------------------------------------------------------------------------------------------- ----
Turn from: http://www.cppblog.com/fwxjj/archive/2011/09/30/157242.aspx
Google provides a Python script that downloads this Python script from http://code.google.com/p/android-ndk-stacktrace-analyzer/and then uses
ADB logcat-d > LogFile Export crash log,
Use Arm-eabi-objdump (located under Build/prebuilt/linux-x86/arm-eabi-4.2.1/bin) to convert so or EXE to assembly code, such as:
Arm-eabi-objdump-s mylib.so > Mylib.asm,
And then use the script
Python parse_stack.py <asm-file> <logcat-file>
