Android Crawl native layer crashing

Using the Android Breakpad tool

Use this tool to download Breakpad source code, and then compile, compile will generate two of tools

Second, Generate conversion tool
1. Download Breakpad Source code
Command line input: SVN checkout Http://google-breakpad.googlecode.com/svn/trunk/google-breakpad-read-only

2. Compiling tools
① Entering the code path
CD google-breakpad-read-only/

② Configuring the Environment
./configure

③ Compilation Tool
Make

3. See if the following tools are present:
Google-breakpad-read-only/src/tools/linux/dump_syms/dump_syms
Google-breakpad-read-only/src/processor/minidump_stackwalk

These two tools can be downloaded directly into the csdn to download the successful compilation

This process you need to compile a few tools: minidump_stackwalk dump_syms and so on

These are the two tools above.

But it's important to note that the different versions here can be downloaded directly to CSDN.

Integration into the app

This process you need to compile the file with Ndk-build, .so put it into the Libs directory in your app project, and initialize the Breakpad in the Java layer, such as the following three steps:

1. Compiling. So files for Android platforms
2. Writing a JNI layer mapping file
3. Copy the. So file and the JNI mapping file into the project

Of course, you can also use open Source: https://github.com/yinyinnie/breakpad-for-android

1. Find the key function pointers in the log

Https://www.cnblogs.com/willhua/p/6718379.html

In fact, it is very simple, is to find backtrace information, belong to our own so file error lines.

First of all to find backtrace information, some of the opportunity to explicitly print a line of backtrace (such as the mobile phone we use this time), then this line of the following a series of "#两位数字 PC" line is backtrace information. Sometimes the phone does not print a line of backtrace, so just find a line that starts with "#两位数字 PC".

Next to find their own so file error lines, this is relatively simple. After you find these rows, note the address of the functions in these lines

2. Find the code location using Addr2line

Execute the following command, multiple pointer addresses can be entered in a command, separated by a space

[Plain] View plain copy

1. Arm-linux-androideabi-addr2line–e obj/local/armeabi/libhello-jni.so 00004de8 000056c8 00004fb4 00004f58

The results are as follows [plain] view plain copy

1. /android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/char_traits.h:229
2. /android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/_string.c:639
3. /wordspaces/hello-jni/jni/hello-jni.cpp:69
4. /wordspaces Hello-jni/jni/hello-jni.cpp:6

As we can see from the results of the addr2line, we get the call relationship and the number of rows for our own error code, In the hello-jni.cpp of 69 rows and 61 lines (the other two lines because the standard function can be ignored), the results and ndk-stack are consistent, indicating that Ndk-stack is also addr2line to get the location of the code.

3. Using Objdump to get function information

With the Addr2line command, we've actually found the wrong place in our code, and we've been able to help the programmer locate the problem. However, this method can only get the number of lines of code, and does not display function information, it is not so "perfect", for the pursuit of the ultimate programmer, this is certainly not enough. We'll show you how to locate the function information below.

Use the following command to export the function table:

[Plain] View plain copy

1. Arm-linux-androideabi-objdump–s obj/local/armeabi/libhello-jni.so > Hello.asm

Find the two key pointers 00004fb4 and 00004f58 that we have just positioned in the generated ASM file

From these two graphs can be clearly seen (note that in different NDK versions and different operating systems, the format of ASM files is not exactly the same, but all the same, please carefully compare), these two pointers belong to the Willcrash () and the Jni_onload () function, respectively, Combined with the results of the addr2line just now, the corresponding information for these two addresses is:

[Plain] View plain copy

1. 00004fb4:willcrash ()/wordspaces/hello-jni/jni/hello-jni.cpp:69
2. 00004f58:jni_onload ()/wordspaces/hello-jni/jni/hello-jni.cpp:61

Quite perfect, and ndk-stack get the information exactly the same!

The addr2line and the relative address in the stack can get the file name and line number. Of course, if you want to have a debug version, a binary file with a symbol table.

Android Crawl native layer crashing