Linux development, the underlying often used statically linked library (* .a) or dynamic link library (* .so) to achieve a certain function.
In the application layer calls so files will often encounter the phenomenon because of internal problems so cause the application to crash in.
After the crash occurs, the system generates a log. Log substantially as follows:
01 |
I/DEBUG(349): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** |
02 |
I/DEBUG(349): Build fingerprint: |
03 |
'Android/jileniao.net/jileniao:5.0.1/LRX22G/root03231947:userdebug/test-keys' |
04 |
I/DEBUG(349): Revision: '33696' |
05 |
I/DEBUG(349): ABI: 'arm' |
06 |
I/DEBUG(349): pid: 2686, tid: 3065, name: gps_proc >>> /system/bin/gpsserver <<< |
07 |
I/DEBUG(349): signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xb170a219 |
08 |
W/NativeCrashListener(856): Couldn't find ProcessRecord for pid 2686 |
09 |
I/DEBUG(349): r0 000fde18 r1 ae3f4248 r2 0007ef0c r3 00008000 |
10 |
E/DEBUG(349): AM write failure (32 / Broken pipe) I/DEBUG(349): r4 001fb799 r5 ffffa7e4 r6 ae4d00c0 r7 0001c5a2 |
11 |
I/DEBUG(349): r8 00000081 r9 00000001 sl b160c400 fp 00000001 |
12 |
I/DEBUG(349): ip ae4d00c0 sp af0bb8a0 lr b160c401 pc b5d08680 cpsr 280b0010 |
13 |
I/DEBUG(349): backtrace: |
14 |
I/DEBUG(349): #00 pc 0011d680 /system/lib/gps_ma87.so (Method0+984) |
15 |
I/DEBUG(349): #01 pc 0007694c /system/lib/gps_ma87.so (Method1+724) |
16 |
I/DEBUG(349): #02 pc 00069c2c /system/lib/gps_ma87.so (Method2+1116) |
17 |
I/DEBUG(349): #03 pc 000676f4 /system/lib/gps_ma87.so (Method3+224) |
18 |
I/DEBUG(349): #04 pc 00066bef /system/lib/gps_ma87.so (GPSCPPClassName::Method4(char*, int)+390) |
19 |
I/DEBUG(349): #05 pc 000438bf /system/lib/gps_ma87.so (gps::Method5(void)+134) |
20 |
I/DEBUG(349): #06 pc 00042fe1 /system/lib/gps_ma87.so (gps::Method6(void*)+40) |
21 |
I/DEBUG(349): #07 pc 00042429 /system/lib/gps_ma87.so (gps::Method7(void*)+172) |
22 |
I/DEBUG(349): #08 pc 000162e3 /system/lib/libc.so (__pthread_start(void*)+30) |
23 |
I/DEBUG(349): #09 pc 000142d3 /system/lib/libc.so (__start_thread+6) |
After seeing the log, directly to the most useful backtrace information. backtrace describes the crash occurred when the relationship between function calls and other address information, etc., can be described as truly restore the crash site. Then you look at the specific circumstances of the scene is kind of how.
backtrace in, from # 00 to # 09 on behalf of a total of ten rows of information is a function call relationship when crash, backwards looking up from under Method # line 09 calls a method of line # 08; # 08 line method call # methods 07 lines; up on, the last is the # 01 line method called method # 00 rows. The crash eventually is in the # 00 line.
Through the above method we know what the problem is when the crash occurred. But one specific method is still somewhat broad, to troubleshoot problems, we also hope to get more detailed results.
In backtrace information, # methods for each row there is a marked XXX + word back 00 to # 09, I am the first to understand that this is the line number. But back to the source code, but found not like that.
To know the exact line number, you must use pc behind each line of the address.
Linux provides addr2line order for us. The line number can be obtained by the address command.
Look at the specific usage addr2line command.
Here we specify two options can achieve the look of the objective function and the line number.
- -E back together so the file name
- -f while the output function name
Examples: addr2line -e test gps_ma87.so 0x0011d680 -f
In this way you can get the function name and the specific number of lines which file.
Addr2line obtained line number is impossible to determine the error
If you use line numbers corresponding source code addr2line command obtained is a very simple assignment statement such a situation, that is, we can not be very sure what this line of code error exceptions. At this place called the method depends on whether there is wrong, call the place most likely on the wrong approach, so the system being given time to locate to this line.
addr2line get line number ??:? or ??: Reason 0
If you encounter addr2line get ??:? Or ??: 0, reason is compiled get so files are not attached on the symbol table (symbolic) information.
If the source environment in android, android build environment automatically generates so there is documentation that came with the symbol table (symbolic) of. In standard android5.0, accompanied by the symbol table (symbolic) so files in the following path:
out/target/product/[productname]/symbols/system/lib/****.so
If a non-android environment, the need comes with the option symbol table (symbolic) of specified documents so generated makefile, in particular with regard to the dynamic link library and symbol tables, etc., please consult the following website: http://tldp.org/HOWTO/Program -Library-HOWTO / shared-libraries.html
