android NDK crash debugging mainly uses tombstones, which can be regarded as debugging and checking problems using core files on ordinary linux
1, Introduction to tombstones
1. What is a tombstone
When the independent ndk bin mode or jni mode starts running, the system will register some information and connect to the debuggerd signal handlers. When the system crashes, a tombstone file will be generated and saved to the / data/tombstones directory. The file is indeed like a tombstone recording the basic information of the dead process (such as the process number and thread number of the process), The address of the death (on which address the Crash occurred), what was the scene of the death (a series of stack call information was recorded), and so on.
2. What does the tombstone file look like
A tombstone file contains the following information
console:/ # cat /data/tombstones/tombstone_00 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** Build fingerprint: 'Allwinner/petrel_p1/petrel-p1:9/PPR1.181005.003/20210826-112106:eng/test-keys' Revision: '0' ABI: 'arm' pid: 1893, tid: 2906, name: bonjour >>> /system/bin/ndktest <<< signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xacc03064 r0 000003ff r1 acc0311c r2 00000004 r3 f3cec54f r4 acbcb640 r5 000000b8 r6 000007c0 r7 ef57f3f8 r8 acbcc8b4 r9 acbd53fc r10 00000400 r11 acbc83d8 ip f3d32638 sp ef57f3b0 lr acb47c5f pc acb47c6a backtrace: #00 pc 000a8c6a /system/bin/ndktest #01 pc 000532e5 /system/bin/ndktest #02 pc 00063a25 /system/lib/libc.so (__pthread_start(void*)+22) #03 pc 0001df95 /system/lib/libc.so (__start_thread+22) stack: ef57f370 00000000 ef57f374 00000000 ef57f378 00000000 ef57f37c 00010000 ef57f380 612709a0
1) . process ID information of the problem
pid: 1893, tid: 2906, name: bonjour >>> /system/bin/ndktest <<<
When tid == pid, the problem occurs in the parent process. On the contrary, the problem occurs in the child process. From the above log information, we can see that the process with the problem is the child process.
2) . cause of collapse
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xacc03064
The information here shows that the process Crash occurs because the program generates a segment error (SIGSEGV) signal and accesses an illegal memory space (0xacc03064).
When a serious error occurs during the execution of a Linux application, it will generally cause the program to crash. Among them, Linux specifically provides a kind of crash signal. When the program receives this kind of signal, the default operation is to record the crash field information to the core file, and then terminate the process.
3) . see where the crash occurred
backtrace: #00 pc 000a8c6a /system/bin/ndktest #01 pc 000532e5 /system/bin/ndktest
Here you can see that the last stack address before the crash is 000a8c6a and 000532e5 of ndktest. How to find the function corresponding to these two addresses? You need to use the tool addr2line. You can use the following command to view it
PS D:\xxx\ndktest\android9.0> D:\xx\android-ndk-r21e\toolchains\arm-linux-androideabi-4.9\prebuilt\windows-x86_64\bin\arm-linux-androideabi-addr2line.exe -e .\obj\local\armeabi-v7a\ndktest 000a8c6a -Cfip crash_test_func at D:\xxx/ndktest.c:47
From the above information, you can see that the 000a8c6a address corresponds to ndktest.c 47 line crash_test_func function.
4) . attention
When using the add2line tool, do not use. \ libs\armeabi-v7a\ndktest, but use the ndktest under. \ obj\local\armeabi-v7a \, because the debugging information has been removed from the files under libs. You can compare that the ndktest under libs is much smaller than that under obj.
5). tombstone_ There is also logcat in 00, and the last moment is recorded. It is easier to analyze the problem by combining a variety of methods