Using the Addr2line tool to parse BackTrace

Coredump is a powerful tool for analyzing Android native exception and kernel exception , the Coredump Chinese name is the core dump, Presumably it can be understood that when the system or a process exception can not be saved, the system mechanism to remove the problem of memory to package the core dump supply system anomaly engineer off-line analysis. With Coredump not only can locate the specific exception of the code in the file line number, can also be offline debugging, step by step restore problem scene, caught out of the abnormal real killer. However, many times because the system hangs too suddenly or some reason too late to pack coredump, resulting in unable to get to the core dump, leaving only a heap of backtrace of residual information for analysis, this lack of debugging information is usually difficult to debug, and this time the GNU The Tools tool family's addr2line tool works, and the Addr2line tool can "translate" specific code locations based on the memory address plus the library's symbol library file parsing, helping to analyze the causes of crashes from log conversion to source code level.

The following is the backtrace of a crash process:

1Revision:'0'2Abi:'arm64'3Pid:24377, Tid:24377, NAME:GX_FPD >>>/SYSTEM/BIN/GX_FPD <<<4Signal6(SIGABRT), code-6(Si_tkill), fault addr--------5X00000000000000000X1 0000000000005f39 x20000000000000006X300000000000000006X40000000000000000X50000000000000001X60000000000000000X700000000000000007x80000000000000083X9 0000007fb4eec110 x100000000000000002X1100000000000000038X120000000000000000X130000000000000043x14 0000007fcc97a768 x1500000000000000009x16 0000007FB4B866A8 x17 0000007fb4b48b6c x180000000000000002x19 0000007fb4f670a8Tenx20 0000007fb4f66fe8 x21 000000000000000b x220000000000000006x23 0000005582219f90 Onex24 0000007fcc97ac90 x25 0000007fb4e04d18 x260000000000000000X270000000000000000 Ax280000000000000000x29 0000007fcc97ab60 x30 0000007fb4b46308 -SP 0000007fcc97ab60 pc 0000007fb4b48b74 pstate0000000020000000 - v0 2e2e2e2e2e2e2e2e2e2e2e2e2e2e2e2e v1 006370692e67756265642e6f6e6e6974 theV2 636f69203a4457540000000000000031 v380000000000000000000000000000000 -V400000000000000008020080280200800V500000000400000000000040000000000 -V600000000000000000000000000000000V780200802802008028020080280200802 -V800000000000000000000000000000000V900000000000000000000000000000000 +V1000000000000000000000000000000000V1100000000000000000000000000000000 -V1200000000000000000000000000000000V1300000000000000000000000000000000 +V1400000000000000000000000000000000V1500000000000000000000000000000000 AV1640100401401004014010040140100401v17 00000000a00aa0080000aaa880400400 atV1800000000000000008020080280200800v19 0833083a082f08240828083c082e0832 - v20 0c950c920c9a0c950c960c950c970c9a v21 000000000000000000000055822a6c18 - v22 083a083e083408380834083b084f084b v23 0c950c960c960c930c970c8d0c930c9a - v24 000000000000000000000055822a6c08 v25 085908470837083f083e083f08410843 - v26 0c950c930c920c940c950c960c920c97 v27 000000000000000000000055822a6bf8 - v28 0862084c084e083b084608350826082e v29 0c920c960c930c950c920c970c900c98 in v30 000000000000000000000055822a6be8 v31 0838083c0850085a08410851082f0846 -Fpsr00000000Fpcr00000000 to  + BackTrace: -#xxPC 000000000006ab74/system/lib64/libc.so (tgkill+8) the# onPc0000000000068304/system/lib64/libc.so (pthread_kill+ the) *# GenevaPC 00000000000212f8/system/lib64/libc.so (raise+ -) $#GenevaPC 000000000001ba98/system/lib64/libc.so (abort+ -)Panax Notoginseng#GenevaPC 000000000002e104/system/lib64/libbinder.so (Android::ipcthreadstate::jointhreadpool (BOOL)+216) -# toPC 0000000000004C5C/SYSTEM/BIN/GX_FPD (main+236) the# .Pc0000000000019794/system/lib64/libc.so (__libc_init+ -) +# -PC 0000000000004D78/SYSTEM/BIN/GX_FPD

From the discovery of abnormal signals signal 6 (SIGABRT) See the first guess is that a null memory range occurred, was intercepted by the MMU, ARM exception processing reported data abort caused by the exception. It is important to know what the source code of the specific backtrace represents,

That is, the backtrace information is translated into specific source-level analysis, while the Addr2line tool provides this functionality.

Usage:

( Be sure to use the library with the Sysmbol directory ) addr2line - e < signed library > < memory address >

The parsing is as follows:

1./AARCH64-LINUX-ANDROID-ADDR2LINE-E symbols/system/lib64/libc.so 000000000006ab742Bionic/libc/arch-arm64/syscalls/tgkill. S93./AARCH64-LINUX-ANDROID-ADDR2LINE-E symbols/system/lib64/libc.so00000000000683044Bionic/libc/bionic/pthread_kill.cpp: $(discriminator1)5./AARCH64-LINUX-ANDROID-ADDR2LINE-E symbols/system/lib64/libc.so 00000000000212f86Bionic/libc/bionic/raise.cpp: the(discriminator1)7./AARCH64-LINUX-ANDROID-ADDR2LINE-E symbols/system/lib64/libc.so 000000000001ba988Bionic/libc/bionic/abort.cpp: -9./AARCH64-LINUX-ANDROID-ADDR2LINE-E symbols/system/lib64/libbinder.so 000000000002e104TenFrameworks/native/libs/binder/ipcthreadstate.cpp:608

= = "

1 BackTrace:2#xxPC 000000000006ab74/system/lib64/libc.so (tgkill+8)Tgkill. S:93# onPc0000000000068304/system/lib64/libc.so (pthread_kill+ the)Pthread_kill.cpp: $4# GenevaPC 00000000000212f8/system/lib64/libc.so (raise+ -)Raise.cpp: the5#GenevaPC 000000000001ba98/system/lib64/libc.so (abort+ -)Abort.cpp: -6#GenevaPC 000000000002e104/system/lib64/libbinder.so (Android::ipcthreadstate::jointhreadpool (BOOL)+216) ipcthreadstate.cpp:608 7# toPC 0000000000004C5C/SYSTEM/BIN/GX_FPD (main+236)8# .Pc0000000000019794/system/lib64/libc.so (__libc_init+ -)9# -PC 0000000000004D78/SYSTEM/BIN/GX_FPD

Note here that because GX_FPD is a third-party library with no symbol, the specific code location cannot be resolved.
Then we can look at the code that happened to the exception, ipcthreadstate.cpp:608

1 voidIpcthreadstate::jointhreadpool (BOOLIsmain)2 {3Log_threadpool ("* * * thread%p (PID%d) is joining the thread pool\n", (void*) pthread_self (), Getpid ());4 5Mout.writeint32 (Ismain?bc_enter_looper:bc_register_looper);6     7     //This thread is been spawned by a thread that is in the background8     //scheduling group, so first we'll make sure it's in the foreground9     //One to avoid performing a initial transaction in the background.Ten Set_sched_policy (Mmythreadid, sp_foreground); One          A status_t result; -      Do { - processpendingderefs (); the         //Now get the next command to be processed, waiting if necessary -result =Getandexecutecommand (); -  -         if(result< No_error && result! = Timed_out && Result! =-econnrefused && Result! =-EBADF) { +Aloge ("Getandexecutecommand (fd=%d) returned unexpected error%d, aborting", -Mprocess->mdriverfd, result); + abort (); A}

The above code can be out, this abort is not caused by a null pointer (above the wrong O (╯-╰) o), but the result of the exception artificially added to the abort () action trap, here you need to analyze why this result is abnormal cause to run into this trap,

And this piece belongs to the core code of binder communication, so we need to understand the principle of binder and its code is very familiar in order to calmly debug analysis to find out the answer.

Using the Addr2line tool to parse BackTrace