In Android development, the program crash in three scenarios: Uncaught exception, ANR (application not responding), and flashback (Ndk throws an error). an uncaught exception in which the stack information printed according to Logcat is easy to locate the error. ANR Error Check, Android rules, when the app interacts with the user, if the user does not respond to the action within 5 seconds, a ANR error is raised, and a system prompt pops up to let the user choose to continue waiting or to close the program immediately. A traces.txt file is generated in the/DATA/ANR directory, which records the stack and thread information that the system generates the ANR exception. If this is a flashback , the problem is more difficult to find, usually in projects where the ndk throws some kind of fatal error causing a flashback. Because the NDK is developed using C/s + +, programmers familiar with C + + know that pointers and memory management are the most important and the most prone to problems, with a slight inadvertent encounter such as memory address access errors, use of wild targets, memory leaks, stack overflows, initialization errors, type conversion errors, The number of common problems, except for 0, leads to the same result: a program crashes. Does not pop up the "XXX program is unresponsive, closes immediately" prompt box like when the Java layer produces an exception. When the NDK error occurs, the Logcat print out of the heap of logs according to understand, and do not want to locate the source of the error from the log, let me often a bit crazy, furious, drink how many jdb are not working. When I tried to print the logs in each JNI function to track the problem, it was too inefficient and could not locate the problem. Good heavens have eyes, let me find the NDK provides several debugging tools to pinpoint the source of the error.
Three debugging tools are available in the NDK installation package: Addr2line, Objdump, and Ndk-stack, where Ndk-stack is placed in the $ndk_home directory, with the Ndk-build sibling directory. Addr2line and Objdump in the NDK cross compiler Toolchain directory, below is the directory structure of my native ndk cross compiler toolchain:
As you can see from the directory structure, the NDK implements multiple sets of identical tools for different CPU architectures. So when choosing the Addr2line and Objdump tools, choose based on the CPU architecture of your target machine. If it is an ARM architecture, select arm-linux-androidabi-4.6/4.8 (high version is generally selected). x86 architecture, select x86-4.6/4.8. Mipsel architecture, select mipsel-linux-android-4.6/4.8. If you do not know the CPU structure of the target machine, connect the phone to the computer and use the ADB shell Cat/proc/cpuinfo to view the CPU information of the phone. It's my native ARM architecture toolchain directory structure:
Here's a sample Hello-jni project to illustrate how to pinpoint errors with the NDK's own example
[CPP]View PlainCopyLine 7th defines a Willcrash function that has an illegal operation in addition to 0, which causes the program to crash. The 13th line of the Jni_onload function calls Willcrash, which is called back after Java loads the. So file, which means the program starts crashing. Here is the log that is printed after running the program:
[CPP]View PlainCopyLog analysis:
Line 3rd starts the app, line 5th tries to load the so in the application Data directory, and line 6th generates a fatal error when loading the so file, and the 7th line fatal signal 8 hints that this is a fatal error, the signal is issued by Linux, Signal 8 means that the floating-point arithmetic is abnormal, it should be done in the Willcrash function in addition to the 0 operation produced. The following focuses on the 15th row of backtrace logs, backtrace logs can be considered as the stack information of the JNI call, the "#两位数字 PC" begins with the BackTrace log. Note that line 20th and line 21 are our own compiled so file and defined two functions, where an exception is thrown, causing the program to crash .
[CPP]View PlainCopybegan to have some clues, but the specific collapse in the position of the two functions, we are not sure, if the function code is less good check, if more complex words, look up also laborious. This time we need to rely on the NDK to provide us with the tools to precisely locate. Before that, let's take a note of the assembly command address that let the program crash, willcrash:00000cf4,jni_onload:00000d1c
Method 1: Use Arm-linux-androideabi-addr2line to locate the error location
Take the ARM architecture CPU as an example and execute the following command:
-e: Specify the so file path
0000CF4 0000d1c: Assembly instruction Address of error
The results are as follows:
is not pleasantly surprised to see the results we want, respectively, in the HELLO-JNI.C 10 and 15 row of the wrong, and then go back to see the source of HELLO-JNI.C, 15 lines of jni_onload function within the call Willcrash functions, Line 10th does the crash caused by an operation other than 0.
Method 2: Use Arm-linux-androideabi-objdump to locate faulty function information
In the first way, through Addr2lin has gotten to the location of the code error, but do not know the function of the context information, it seems a little less "perfect" for me to pursue the ultimate, this is obviously not enough, let's look at how to locate the function information.
First, use the following command to export the function table information for so:
In the generated ASM file, locate the two wrong assembly instruction addresses that we started to locate (search for CF4 in the file or Willcrash can be found), as shown in:
In this way, you can also find out which function the two wrong pointer addresses are in.
Way 3:ndk-stack
If you feel that the above method is too cumbersome, ndk-stack can help you reduce the number of steps, directly to the location of the code error.
Real-time Analytics logs:
Use ADB to get the log of the Logcat and pass the pipeline output to the Ndk-stack analysis and specify the so file location that contains the symbol table. If your program contains multiple CPU architectures, you need to choose a different CPU architecture directory based on the CPU type of your phone. Take the ARMV7 architecture as an example and execute the following command:
[CPP]View PlainCopyWhen the program occurs crash, the following information is output:
[CPP]View PlainCopyLines 7th and 8th print out the error location in the source file, just as the addr2line results.
Get log re-analysis first:
This approach is similar to the one above, except that the source of the log is not the same. For apps or games to test the test department, the tester discovers crash, saves the log file with ADB Logcat, and sends it to the programmer for analysis through the Ndk-stack command. The operation flow is as follows:
The result is the same as the above method.
Transferred from: http://blog.csdn.net/xyang81/article/details/42319789
Android NDK development Crash error targeting
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
