Android platform crawl native crash log

Android development, the Java layer can easily capture crashlog, but for the Native layer of crashlog is usually not directly accessible, only through the system's Logcat to analyze crash logs.

Both Linux and WIN32 developers know that when the program crash on a PC, the core dump file can be generated to parse the function call stack and the memory information at the time of the crash with related tools.

So, as a software developer, is there a way to get the native layer of crashlog? Android is the Linux kernel, and since you can generate dump files when crash in Linux, there are ways to do it in Android.

Crash Dumplinux stack call backtracking for Linux systems

For Linux applications, the constructor's function call chain is relatively easy because of the support of the GLIBC library. The core function of a series of library functions provided by the GLIBC library on stack back is backtrace() . It is responsible for traversing all stack frames from the program entry point to the current call point, and then generating the address sequence of the function call. To complete the conversion of the function address and function name, the function is backtrace_symbols() responsible for backtrace() converting the resulting address sequence into a series of string lists, including the function name in each string list, the offset of the current instruction in the function, and the return address of the function. Due to the backtrace_symbols() need to dynamically request space to hold a list of strings, if the application crash the system memory, it may result in an backtrace_symbols () result error. To do this, the GLIBC library also provides a more secure address translation function: backtrace_symbols_fd() . The function outputs the resulting string directly to an external file without needing to request a new memory space. For backtrace() a detailed usage method, you can man backtrace view the.

In Andrid, because Google did not use the GLIBC library, it used a streamlined version of the Bionic Library, which was not backtrace() available. There are other ways to get the call stack.

Linux signaling mechanism

Signaling mechanism is an important way of communication between Linux processes, and the Linux signal is used for normal interprocess communication and synchronization, such as task control (SIGINT, Sigtstp,sigkill, Sigcont, ...). On the other hand, it is also responsible for monitoring system anomalies and interruptions. When an application runs an exception, the Linux kernel generates an error signal and notifies the current process. After the current process receives the error signal, there are three different ways to handle it. 1. Ignore the signal.
2. Capture the signal and execute the corresponding signal processing function (signal handler).
3. The default action for performing this signal, such as SIGTERM, is to terminate the process.

When a Linux application executes with a critical error, it generally causes the program to crash. Linux specifically provides a class of crash signals, when the program receives such signals, the default action is to log Crash's field information to the core file, and then terminate the process.

Crash Signal List

Signal	Description
SIGSEGV	Invalid Memory Reference.
Sigbus	Access to an undefined portion of a memory object.
SIGFPE	Arithmetic operation error, like divide by zero.
Sigill	Illegal instruction, like execute garbage or a privileged instruction
Sigsys	Bad system call.
Sigxcpu	CPU time limit exceeded.
Sigxfsz	File size limit exceeded.

Linux Signal Processing Sigaction

  #include <signal.h> int sigaction (int sig, struct sigaction *act, struct sigaction *oact);     struct sigaction{void (*sa_handler) (int);     void (*sa_sigaction) (int, siginfo_t *, void *);     sigset_t Sa_mask;     int sa_flags;  void (*sa_restorer) (void); }

This function can: 1. Install a handler for a signal, and do not reinstall before using Sigaction to modify the handler. 2. Using the sigaction structure, the structure contains handler, which can specify 2 handler, one is handler using parameters such as sigiinfo_t, that is, support to handler more parameters, so that they can know what process they are, that user, What signal is sent to the specific reason for the signal, of course, like this, to sigaction sa_flags set sa_siginfo tag. 3. The sa_flags tag with sigaction can also specify whether the system call is returned directly or automatically restart after the signal is interrupted. A typical example is that we do not allow the SIGALRM signal to be interrupted by a system called restart, because Sigalarm is generally used to interrupt a block invocation. 4. In order to imitate the function of the old signal function, implementation of unreliable similar signal operation, can be set to Sa_flags Sa_resethand so handler will not automatically reinstall, and Sa_ Nodefer Mark to the handler inside this signal, this signal is not automatically block, of course, if you manually specify in the Sa_mask block this signal, you can block it. 5. By using the Sa_mask in the sigaction structure, you can block some signals during the execution of the handler, note that this mask is different from the mask we use for the Sigprocmask settings, This mask is scoped to the handler function only, and he will not cancel us with the mask set by Sigprocmask, but only on the basis of a few signals again block off, when the end of the handler, the system will automatically restore mask to the previous appearance, So the sa_mask in this sigaction only acts on the handler execution time of this signal.

An example of signal processing using sigaction:

#include <signal.h>void sig_handler_with_arg(int sig,siginfo_t *sig_info,void *unused){……}int main(int argc,char **argv){    struct sigaction sa;      sigemptyset(&sa.sa_mask);    sa.sa_sigaction = sig_handler_with_arg;    sa.sa_flags = SA_RESETHAND;sigaction(SIGSEGV, &sa, NULL);... }

Android Tombstones Analysis

When Nativecrash is applied to an Android system, the /data/tombstones tombstone_xx log file is generated in the directory and the memory, register, stack information, etc. are recorded when the application crash occurs. and output its contents through Logcat.

The source code for the Tombstones Processing section in Android 4.0 is located in /system/core/debuggerd and bonic/linker/debugger.c .

In bonic/linker/debugger.c the middle of the debugger_init() 7 signal are registered processing, debugger_signal_handler as a signal processing function.

void debugger_init(){  struct sigaction act;  memset(&act, 0, sizeof(act));  act.sa_sigaction = debugger_signal_handler;  act.sa_flags = SA_RESTART | SA_SIGINFO;  sigemptyset(&act.sa_mask);  sigaction(SIGILL, &act, NULL);  sigaction(SIGABRT, &act, NULL);  sigaction(SIGBUS, &act, NULL);  sigaction(SIGFPE, &act, NULL);  sigaction(SIGSEGV, &act, NULL);  sigaction(SIGSTKFLT, &act, NULL);  sigaction(SIGPIPE, &act, NULL);}

In debugger_signal_handler , the socket client communicates with the socket server in the/system/core/debuggerd, and the analysis of the crash process in the/system/core/debuggerd ( handle_crashing_process function) , Generate a tombstones file ( dump_crash_report function).

unwind_backtrace_with_ptraceThe function obtains the Backtrae, reading the register and the associated memory address through the ptrace.

Google Breakpad Projects

Google Breakpad is the Google Open source cross-platform crash dump and Analysis module that supports Windows,linux and Mac and Solaris systems and can be compiled into Android engineering. The advantage of Google-breakpad is that it can block differences in different platforms, record and analyze symbol file formats and crash stack information using a unified file format.

On Linux systems, Google-breakpad is also a signal mechanism to capture crash, the approximate process can be learned through the source notes:

The signal flow looks like this://Signalhandler (uses a global stack of Exceptionhandler objects to find//         | One to handle the signal.         If the first rejects it, try//| The second etc ...) v//handlesignal----------------------------|                                   (Clones a new process which//|  |  Shares an address space with//(Wait for cloned | The crashed process.  this//process) |                                   Allows us to ptrace the crashed//|  | Process)//V v//(set signal handler to Threadentry (static functio      N to bounce//SIG_DFL and rethrow, |                                          Back into the object)//killing the crashed |//process) v//                                      Dodump (writes minidump)//      |//v//Sys_exit 

The use of Google-breakpad in the client is also very simple, you can refer to the official Wiki tutorial documentation: How to ADD Breakpad to Your Linux application.

Android platform crawl native crash log