Common errors:
Initialization error
Array / iterator / pointer access out of bounds
Access invalid / null pointer object
Memory leak
Parameter error
stack overflow
Type conversion error
etc.
1. Log and its explanation:
Log collection already exists by default. If you test and collect logs yourself, you can directly: ADB logcat - B crash > logs txt
06-30 18:19:07.867 F/DEBUG (32224): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 06-30 18:19:07.868 F/DEBUG (32224): Build fingerprint: 'Redmi/phoenix/phoenix:10/QKQ1.190825.002/V11.0.13.0.QGHCNXM:user/release-keys' 06-30 18:19:07.868 F/DEBUG (32224): Revision: '0' 06-30 18:19:07.868 F/DEBUG (32224): ABI: 'arm' 06-30 18:19:07.868 F/DEBUG (32224): Timestamp: 2021-06-30 18:19:07+0800 06-30 18:19:07.868 F/DEBUG (32224): pid: 32190, tid: 32214, name: Thread-3 >>> com.eastmoney.avdemo <<< 06-30 18:19:07.868 F/DEBUG (32224): uid: 10432 06-30 18:19:07.868 F/DEBUG (32224): signal 4 (SIGILL), code 1 (ILL_ILLOPC), fault addr 0xc275e21c (*pc=0x03eeca) 06-30 18:19:07.868 F/DEBUG (32224): r0 00000000 r1 adc5b26a r2 00430000 r3 00000003 06-30 18:19:07.868 F/DEBUG (32224): r4 c275dfc5 r5 d3ced500 r6 bfb83000 r7 c207b938 06-30 18:19:07.868 F/DEBUG (32224): r8 00000000 r9 d2df1200 r10 c207ba68 r11 c207b9ec 06-30 18:19:07.868 F/DEBUG (32224): ip eb3f7464 sp c207b920 lr eb38a51f pc c275e21c 06-30 18:19:07.893 I/chatty ( 891): uid=1000(system) Binder:891_1 identical 2 lines 06-30 18:19:07.913 D/BufferQueueLayer( 891): Launcher new frame Arrived 06-30 18:19:07.919 W/AudioFlinger( 886): RecordThread: buffer overflow 06-30 18:19:07.927 D/BufferQueueLayer( 891): Launcher new frame Arrived 06-30 18:19:08.057 F/DEBUG (32224): 06-30 18:19:08.057 F/DEBUG (32224): backtrace: 06-30 18:19:08.057 F/DEBUG (32224): #00 pc 0000b21c /data/app/com.eastmoney.avdemo-YiP_dJ7q3lJ9XUmWTX0t-g==/lib/arm/libmp3lame.so (Java_com_eastmoney_avdemo_MainActivity_encode+108) (BuildId: cb7c357001d8fce8380f5394bdd068f61a6f8b13) 06-30 18:19:08.057 F/DEBUG (32224): #01 pc 00009101 /data/app/com.eastmoney.avdemo-YiP_dJ7q3lJ9XUmWTX0t-g==/oat/arm/base.odex (art_jni_trampoline+120) 06-30 18:19:08.057 F/DEBUG (32224): #02 pc 000d7bc5 /apex/com.android.runtime/lib/libart.so (art_quick_invoke_stub_internal+68) (BuildId: 6849d5cbd4a7a5761647e62bbaa3d8d6) ...
The log meaning is roughly explained as follows (according to the line):
The second line is the fingerprint of the current rom, which generally includes the brand of the mobile phone (redmi), android system version (10), MIUI Version (V11.0.13.0.QGHCNXM), release version (the internal test version of rom is debug version);
The fourth line is the current cpu architecture: arm;
The fifth line is the timestamp of crash: 2021-06-30 18:19:07 + 0800;
The sixth line is the current process Id, thread Id \ name and applicationId (generally, if the main thread crash es, the process Id here is the same as the thread Id);
Behind is
Error address: fault addr 0xc275e21c (*pc=0x03eeca);
dump information of register: rx/dx, etc. (r0 00000000 r1 adc5b26a r2 00430000 r3 00000003);
Call stack information where crash occurs: #00 pc 0000b21c /data/app/com.
You can see from the above log that your so library is libmp3lame so，
2. Use the tool to locate the problem code
2.1，ndk-stack
The backtrace in the above log already displays the call stack of the code. If it is not displayed, you can use the ndk stack tool provided by ndk to convert it into a log with call stack information. The command format and usage are as follows:
Format:
Usage: ndk-stack -sym PATH [-dump PATH] Symbolizes the stack trace from an Android native crash. -sym PATH sets the root directory for symbols -dump PATH sets the file containing the crash dump (default stdin) See <https://developer.android.com/ndk/guides/ndk-stack.html>.
use
D:\>ndk-stack -sym D:\Work\WorkSpace\AVDemo\app\build\intermediates\ndkBuild\release\obj\local\armeabi\libmp3lame.so -dump D:\logs.txt
Get the following:
#00 pc 0000b21c /data/app/com.eastmoney.avdemo-YiP_dJ7q3lJ9XUmWTX0t-g==/lib/arm/libmp3lame.so (Java_com_eastmoney_avdemo_MainActivity_encode+108)
Note that the above so library is provided with symbols, which is much larger than that packaged in apk. The location of the project is: app \ build \ intermediates \ ndkbuild \ debug \ obj \ local \ armeabi \ libmp3lame so.
Also, the line number above is not the line number in the source code, but the call order can also be seen through the up and down lines.
2.2，addr2line.exe
To know the specific source code call line number, you need to use arm linux Android addr2line exe，
Use format:
arm-linux-androideabi-addr2line –e XXXX.so pc address 1 pc address 2
As follows:
D:\Program_Files\NDK\android-ndk-r13b-windows-x86_64\android-ndk-r13b\toolchains\arm-linux-androideabi-4.9\prebuilt\windows-x86_64\bin>arm-linux-androideabi-addr2line.exe -e D:\Work\WorkSpace\AVDemo\app\build\intermediates\ndkBuild\release\obj\local\armeabi\libmp3lame.so 0000b21c D:/Work/WorkSpace/AVDemo/app/src/main/cpp/lame/./native-lib.cpp:26
2.3，objdump.exe
If you still want to see the so converted files, you can use the objdump tool, which can confirm which method corresponds to the specific error address again.
The command is as follows:
D:\>D:\Program_Files\NDK\android-ndk-r13b-windows-x86_64\android-ndk-r13b\toolchains\arm-linux-androideabi-4.9\prebuilt\windows-x86_64\bin\arm-linux-androideabi-objdump.exe -S D:\Work\WorkSpace\AVDemo\app\build\intermediates\ndkBuild\release\obj\local\armeabi\libmp3lame.so > lxs.asm
Obtained LXS The ASM file is as follows:
extern "C"
JNIEXPORT jint JNICALL
Java_com_eastmoney_avdemo_MainActivity_encode(JNIEnv *env, jobject thiz, jbyteArray buffer_l,
jbyteArray buffer_r, jint length) {
b1b0: b5f0 push {r4, r5, r6, r7, lr}
b1b2: af03 add r7, sp, #12
b1b4: b083 sub sp, #12
b1b6: b404 push {r2}
b1b8: bc40 pop {r6}
b1ba: 9601 str r6, [sp, #4]
b1bc: b401 push {r0}
b1be: bc20 pop {r5}
...
b20a: b420 push {r5}
b20c: bc01 pop {r0}
b20e: 9901 ldr r1, [sp, #4]
b210: b440 push {r6}
b212: bc04 pop {r2}
b214: 9b02 ldr r3, [sp, #8]
b216: f031 fd23 bl 3cc60 <__aeabi_llsl+0x16c>
b21a: 46c0 nop ; (mov r8, r8)
b21c: 0003eeca .word 0x0003eeca
As can be seen from the last line of the figure above, it corresponds to the error address: fault addr 0xc275e21c (*pc=0x03eeca).
You can see that the last line in the code does not have a render, resulting in a crash.