Android Native crash log analysis, androidcrash

Android Native crash log analysis, androidcrash

In the crash type of Android applications, the native type crash should be a relatively difficult one, because there are few contacts, and then there are several more steps to switch, most of them are unfamiliar with this. Although there are many related articles, I still encountered some problems in the course of my first learning. I will record them one by one for future reading.

Several things are required to analyze native crash logs:

　　Log

Native crash logs are from the planetary number (******************************* *****************) at the beginning, this planet number is also the identifier of the ndk-stack tool for finding native crash. An native crash log example:

 1 04-16 11:18:00.323 26512 26512 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 2 04-16 11:18:00.324 26512 26512 F DEBUG   : Build fingerprint: 'nubia/NX531J/NX531J:7.1.1/NMF26F/nubia04130311:user/release-keys' 3 04-16 11:18:00.324 26512 26512 F DEBUG   : Revision: '0' 4 04-16 11:18:00.324 26512 26512 F DEBUG   : ABI: 'arm' 5 04-16 11:18:00.324 26512 26512 F DEBUG   : pid: 26452, tid: 26491, name: Thread-4  >>> com.willhua.opencvstudy <<< 6 04-16 11:18:00.324 26512 26512 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xc8080000 7 04-16 11:18:00.324 26512 26512 F DEBUG   :     r0 c807a400  r1 c7e80000  r2 00000069  r3 00000069 8 04-16 11:18:00.324 26512 26512 F DEBUG   :     r4 caa4ca9c  r5 007e9000  r6 00000964  r7 c69838f8 9 04-16 11:18:00.324 26512 26512 F DEBUG   :     r8 00005c00  r9 00017002  sl 001fa400  fp cac6ec0010 04-16 11:18:00.324 26512 26512 F DEBUG   :     ip e71aac64  sp c69838e8  lr caa8e949  pc caa8e97c  cpsr 800f003011 04-16 11:18:00.326 26512 26512 F DEBUG   : 12 04-16 11:18:00.326 26512 26512 F DEBUG   : backtrace:13 04-16 11:18:00.326 26512 26512 F DEBUG   :     #00 pc 0004097c  /data/app/com.willhua.opencvstudy-1/lib/arm/libOpenCV.so (_Z14darkGrayThreadPv+179)14 04-16 11:18:00.326 26512 26512 F DEBUG   :     #01 pc 000475d3  /system/lib/libc.so (_ZL15__pthread_startPv+22)15 04-16 11:18:00.326 26512 26512 F DEBUG   :     #02 pc 00019d3d  /system/lib/libc.so (__start_thread+6)

 

　　So file with symbols

For mobile phone company Developers, The so with symbols corresponding to the problematic so is generally under the out/target/product/<model_name>/symbols/system/lib, for a single application developed using AndroidStudio, the corresponding so with symbols under <PROJECT_ROOT> \ app \ src \ main \ obj \ local \ <ABI>, it cannot be \ app \ src \ main \ libs \ <ABI>. Here it does not contain the symbols information. The output result is "?". :?". In fact, the volume comparison between the two so is also very obvious. In my application, the first so with symbols has more than 7 MB, and the last one only has 2 MB.

 

　　Analysis Tools

• Addr2line: used to analyze the number of lines of source code corresponding to a single pc address. For example, #00 pc 0004097c and 0004097c in line 1 of the sample log are the stack address called by the pc during crash, this address can be used to analyze the number of lines in the source code;
• Objdump: used to convert the corresponding so into the asm file of the assembly language, and then find more detailed information about related functions based on the address information (such as 0004097c;
• Ndk-stack: it is used to translate all the log information into a more detailed log with the source code line information, equivalent to executing the addr2line command in the entire crash stack information.

For linux systems used as the development environment, the addr2line command is provided in linux. For Windows, after NDK is installed in the sdk, these tools are included in the ndk.

For example, addr2line tool in: sdk \ ndk-bundle \ toolchains \ arm-linux-androideabi-4.9 \ prebuilt \ windows-x86_64 \ bin, and this bin contains many other tools, such as objdump, readelf;

The ndk-stack tool is under the sdk \ ndk-bundle;

For specific use of these tools.

Note: The crash log must correspond to the corresponding so. That is, the error is: you have taken an old log, modified the source code related to so, and compiled the new so, if you take the new so and the address in the old log for analysis such as addr2line, it is definitely not correct.

 

 

 

The article I just mentioned is very detailed. I will copy it here to avoid finding it later.

/*************************************** **************************************** **************************************** *****************/