本文主要是介绍Android平台抓取native crash log，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
转自：http://www.cnblogs.com/shakin/p/4268399.html
Android开发中，在Java层可以方便的捕获crashlog，但对于 Native 层的 crashlog 通常无法直接获取，只能通过系统的logcat来分析crash日志。
做过 Linux 和 Win32 开发的都知道，在pc上程序crash时可以生成 core dump 文件通过相关的工具分析函数调用堆栈及崩溃时的内存信息。
那么作为软件开发者有没有方法自己获取native层的crashlog呢？Android 系统是 Linux 内核，既然在Linux中crash时可以生成dump文件，那么在Android中也是有办法的。
Linux系统的Crash dump
Linux 栈调用回溯
对 Linux 应用程序而言， 因为有 glibc 库的支持， 所以构造程序的函数调用链相对容易。在 glibc 库提供的关于堆栈回朔的一系列库函数中，其核心函数是 backtrace()。它负责遍历从程序入口点到当前调用点的所有堆栈帧，然后生成函数调用的地址序列。为了完成函数地址和函数名称的转换，函数backtrace_symbols() 负责将 backtrace()生成的地址序列转换成一系列字符串列表，在每个字符串列表中包括了函数名称，当前指令在函数中的偏移量和函数的返回地址。由于 backtrace_symbols() 需要动态申请空间以保存字符串列表，如果应用程序 crash 时破坏了系统内存，可能导致 backtrace_symbols()结果错误。为此，glibc库还提供了一个更安全的地址转换函数：backtrace_symbols_fd() 。该函数将生成的字符串直接输出到外部文件，而不再需要申请新的内存空间。对于 backtrace() 的详细使用方法可以通过man backtrace 查看。
在Andrid中，由于谷歌没有使用glibc库，而是使用了精简版本的bionic库，其中并没有 backtrace() 可用。获取调用堆栈还需要采用其他方法。
Linux 信号机制
信号机制是 Linux 进程间通信的一种重要方式，Linux 信号一方面用于正常的进程间通信和同步，如任务控制(SIGINT, SIGTSTP,SIGKILL, SIGCONT，……)；另一方面，它还负责监控系统异常及中断。 当应用程序运行异常时， Linux 内核将产生错误信号并通知当前进程。 当前进程在接收到该错误信号后，可以有三种不同的处理方式。 1. 忽略该信号。
2. 捕捉该信号并执行对应的信号处理函数(signal handler)。
3. 执行该信号的缺省操作(如 SIGTERM， 其缺省操作是终止进程)。
当 Linux 应用程序在执行时发生严重错误，一般会导致程序 crash。其中，Linux 专门提供了一类 crash 信号，在程序接收到此类信号时，缺省操作是将 crash 的现场信息记录到 core 文件，然后终止进程。
Crash信号列表
| 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 信号处理 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);
}
这个函数可以: 1. 给一个signal安装一个handler，并且在使用sigaction修改该handler之前，不用reinstall。 2. 使用sigaction结构，该结构包含handler，其中可以指定2个handler，一个是使用sigiinfo_t等参数的handler，即支持给handler更多的参数，使其可以知道自己是被什么进程，那个用户，发来的什么信号，发来该信号的具体的原因是什么，当然要像这样，得给sigaction的sa_flags设置SA_SIGINFO标记。 3．使用sigaction的sa_flags标记还可以指定系统调用被这个信号打断后，是直接返回，还是自动restart. 一个典型就是，一般我们不让SIGALRM信号将被打断的系统调用restart，因为SIGALARM一般本来就是用来打断一个block的调用的。 4. 为了模仿老的signal函数的作用，实现unreliable 的类似signal的操作，可以通过给sa_flags设置SA_RESETHAND使handler不会自动reinstall,以及SA_NODEFER标记来使在本信号的handler内部，本信号不被自动block，当然如果你手动在sa_mask中指定要block本信号的话就可以将其block了。 5. 通过使用sigaction结构中的sa_mask，可以在该handler执行的过程中，block一些信号，注意，这个mask是与我们使用sigprocmask设置的mask不同的mask，这个mask的作用范围仅限于本handler函数，而且他不会将我们用sigprocmask设置的mask取消，而仅仅是在其基础上再次将一些信号block掉，当handler结束时，系统会自动将mask恢复成以前的样子，所以这个sigaction中的sa_mask只作用本信号的handler的执行时间。
一个使用 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 分析
Android系统中应用出现nativecrash时，会在 /data/tombstones 目录下生成 tombstone_xx 的日志文件，记录了应用crash发生时的内存、寄存器、堆栈信息等。并且通过logcat将其内容输出。
Android 4.0中tombstones处理部分的源码位于 /system/core/debuggerd 和 bonic/linker/debugger.c 中。
在 bonic/linker/debugger.c 中的 debugger_init() 中对7个Signal进行了注册处理,debugger_signal_handler作为信号处理函数。
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);
}
在debugger_signal_handler 中，通过socket client 与 /system/core/debuggerd 中的socket server进行通信，在/system/core/debuggerd中进行crash进程的分析( handle_crashing_process 函数中)，生成tombstones文件（dump_crash_report 函数）。
unwind_backtrace_with_ptrace 函数获取backtrae，通过 ptrace 读取寄存器和相关内存地址。
Google Breakpad 项目
Google Breakpad 是Google开源的跨平台崩溃转储和分析模块，他支持Windows，Linux和Mac和Solaris系统，并可以编译到Android工程中。Google-breakpad的好处在于可以屏蔽了不同平台的差异，使用统一的文件格式记录和分析符号文件格式和崩溃栈信息。
在Linux系统上，google-breakpad也是通过信号机制来捕获crash，大致过程可以通过源码中的注释了解：
// 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 function to bounce
// SIG_DFL and rethrow, | back into the object)
// killing the crashed |
// process) V
// DoDump (writes minidump)
// |
// V
// sys_exit
客户端中google-breakpad的使用也很简单，可以参照官方wiki的教程文档：How To Add Breakpad To Your Linux Application 。
这篇关于Android平台抓取native crash log的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
