iOS app崩溃捕获

1、信号的理解

信号的概念:
信号(本人关于signal的一篇博客) http://www.jianshu.com/p/cfd8e9824f54

2、Mach异常和Unix信号

Exception Type项通常会包含两个元素: Mach异常 和 Unix信号。

Exception Type:         EXC_BAD_ACCESS (SIGSEGV)     //EXC_BAD_ACCESS是Mach异常 ,SIGSEGV是UNIX信号

Mach异常是什么?它又是如何与Unix信号建立联系的?我们接下来一一解答:
Mach异常: Mach异常是指最底层的内核级异常,被定义在 下 。
每个threadtaskhost都有一个异常端口数组,Mach的部分API暴露给了 用户态 ,用户态的开发者可以直接通过Mach API设置thread,task,host的异常端口,来捕获Mach异常,抓取Crash事件。
UNIX信号: 所有的Mach异常都在host层被转换成相应的UNIX信号,并通过threadsignal将信号投递到出错的线程。(iOS中的 POSIX API 就是通过 Mach 之上的 BSD 层实现的。)

因此: EXC_BAD_ACCESS (SIGSEGV)表示的意思是:Mach层的EXC_BAD_ACCESS异常在host层被转换成了SIGSEGV信号,并投递到出错的线程。

iOS app崩溃捕获_第1张图片
posix-bsd-mach层级.png

其他 : POSIX 可移植接口,Mach异常转化成UNIX信号的原因是为了兼容更为流行的POSIX标准,让不了解Mach内核的人也可以通过UNIX信号的方式来兼容开发。(即:可以通过注册signalHandler来捕获信号:

signal(SIGABRT, SIG_DFL);
signal(SIGILL, SIG_DFL);
signal(SIGSEGV, SIG_DFL);
signal(SIGFPE, SIG_DFL);
signal(SIGBUS, SIG_DFL);
signal(SIGPIPE, SIG_DFL);

Mach异常如何转化为UNIX信号这篇文章写的较为详细:
https://www.jianshu.com/p/725e7d69272c

Mach异常和UNIX信号都可以抓取crash事件,这两种方式哪个更好?
优选Mach异常,因为Mach异常处理会先于Unix信号处理发生,如果Mach异常的handler让程序exit了,那么Unix信号就永远不会到达这个进程了。

另外有一点需要注意的是:

因为硬件产生的信号(通过CPU陷阱)被Mach层捕获后,先产生Mach异常,然后才转换为对应的Unix信号;所以苹果为了统一机制,将操作系统用户产生的信号(通过调用kill和pthread_kill) 也先沉下来被转换为Mach异常,再转换为Unix信号。
关于 调用kill和pthread_kill在实际的操作中我们会用到,用来让用户自己产生Unix信号。

3、Crash收集的实现思路

如上述所说,可以通过捕获Mach异常、或Unix信号两种方式来抓取crash事件,于是总结起来实现方案就一共有3种。

1)Mach异常方式

基于Mach内核编程,需要对内核有一定了解

iOS app崩溃捕获_第2张图片
内核crash收集的流程.png

具体代码看下图
iOS app崩溃捕获_第3张图片
代码实现.png

关于内核异常的捕获这里有一点需要提的是:在我们debug时内核异常(例如:EXC_BAD_ACESS)出现时,xcode就会停止运行,假如我们通过注册了signal()来捕获相应的crash,但是在debug状态下,发生crash并不能执行到通过signal注册的回调函数中,因为:手机的debugserver会直接接收到内核抛出的异常,接收到异常后没有将mach异常转换成相应的signal。最后把内核异常直接抛给了xcode,所以我们通过signal()注册的回调函数无法被回调,因为没有signal产生。(还有一种说法:我们在调试手机上的应用时,并不是mac上的lldb直接加载上了手机中的应用,而是通过手机上的debugserver中转一次加载的,而debugserver可以接收到内核抛出的异常,在接到异常后直接捕获住而并没有透明地传给lldb,就导致我们mac上的lldb什么都干不了了。个人觉得好像不太成立)。
参考上面捕获mach异常的方式,可以通过设置手机debugserver的异常捕获端口来把原有的覆盖掉。

#include 
#include 
#include 
//+load函数
int ret = task_set_exception_ports(
                                       mach_task_self(),
                                       EXC_MASK_BAD_ACCESS,
                                       MACH_PORT_NULL,//m_exception_port,
                                       EXCEPTION_DEFAULT,
                                       0);

这时在xcode层就会得到一个信号。在lldb中输入相关命令(具体方式见下方),就可以执行我们注册的回调。从而达到:‘在debug时遇到EXC_BAD_ACESS等内核异常是,我们的程序能够继续执行。’
当然这是一个插曲。通常情况下我们是没有这种需求的,更多的是如何去定位到产生EXC_BAD_ACESS的位置。

2)Unix信号方式

signal(SIGSEGV,signalHandler);

3)Mach异常+Unix信号方式

目前已知的开源项目包括同行业内朋友交流,基本上都是采用这种方式(念茜文章中也提到这一点,要是各位有更好的方式,可以一起交流)。
虽然优先捕获Mach异常,但是对Mach_CRASH异常我们却不去处理,而是从Unix信号层面,捕获与之对应的SIGABRT信号。原因如下:著名开源项目plcrashreporter在代码注释中给出了详细的解释:(捕获Mach_CRASH时会导致死锁,所以转换为捕获SIGABRT信号)

We still need to use signal handlers to catch SIGABRT in-process. The kernel sends anEXC_CRASH mach exception to denote SIGABRT termination. In that case, catching the Mach exception in-process leads to process deadlock in an uninterruptable wait. Thus, we fall back on BSD signal handlers for SIGABRT, and do not register forEXC_CRASH.

应用级的异常NSException,需要特殊处理,需要去获取它的reasonnamecallStackSymbols信息才能确定出问题的程序位置。因为出现NSException异常后,函数的栈中不会有出错的代码,例如下面这样:

0       libsystem_kernel.dylib          0x3a61757c   __semwait_signal_nocancel + 0x18
1       libsystem_c.dylib               0x3a592a7c   nanosleep$NOCANCEL + 0xa0
2       libsystem_c.dylib               0x3a5adede   usleep$NOCANCEL + 0x2e
3       libsystem_c.dylib               0x3a5c7fe0   abort + 0x50
4       libc++abi.dylib                 0x398f6cd2   abort_message + 0x46
5       libc++abi.dylib                 0x3990f6e0   default_terminate_handler() + 0xf8
6       libobjc.A.dylib                 0x3a054f62   _objc_terminate() + 0xbe
7       libc++abi.dylib                 0x3990d1c4   std::__terminate(void (*)()) + 0x4c
8       libc++abi.dylib                 0x3990cd28   __cxa_rethrow + 0x60
9       libobjc.A.dylib                 0x3a054e12   objc_exception_rethrow + 0x26
10      CoreFoundation                  0x2f7d7f30   CFRunLoopRunSpecific + 0x27c
11      CoreFoundation                  0x2f7d7c9e   CFRunLoopRunInMode + 0x66
12      GraphicsServices                0x346dd65e   GSEventRunModal + 0x86
13      UIKit                           0x32124148   UIApplicationMain + 0x46c
14      XXXXXX                          0x0003b1f2   main + 0x1f2
15      libdyld.dylib                   0x3a561ab4   start + 0x0

通过读取NSExcption对象的callStackSymbols我们可以获取到的精准的调用信息,如下:

*** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[<__NSDictionaryI 0x14554d00> setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key key.'
>Last Exception Backtrace:
0 CoreFoundation 0x2f8a3f7e     __exceptionPreprocess + 0x7e
1 libobjc.A.dylib 0x3a054cc     objc_exception_throw + 0x22
2 CoreFoundation 0x2f8a3c94     -[NSException raise] + 0x4
3 Foundation 0x301e8f1e         -[NSObject(NSKeyValueCoding) setValue:forKey:] + 0xc6
`4 DemoCrash 0x00085306          -[ViewController crashMethod] + 0x6e`
5 DemoCrash 0x00084ecc          main + 0x1cc
6 DemoCrash 0x00084cf8          start + 0x24

关于应用级异常NSException的捕获方法很简单,使用NSUncaughtExceptionHandler函数: 具体事例如下:

static void customExceptionHandle (NSException *exception) {
    //NOTE:Wang Haoyu - 这里可以取到 NSException 信息,reason、callStack...
}
NSSetUncaughtExceptionHandler(&customExceptionHandle);

4、Crash 日志收集存在的陷阱

主要有两类:1)多个Crash日志收集服务共存 2)Objc野指针类的Crash。

多个Crash日志收集服务共存的坑

1)拒绝传递 UncaughtExceptionHandler
如果有多个服务都通过NSSetUncaughtExceptionHandler注册了异常回调函数,如果在回调函数中直接退出了,那后面注册的回调函数就不会起作用。所以需要在注册异常处理函数时需要做两件事

1、排查有哪些服务注册了回调函数,并做了不规范处理(即:在他的回调函数中直接退出了.借助fishHook等工具)。
2、拿到之前的服务注册的handler,然后备份,等自己的回调函数处理完后再把之前备份的handler注册回去。

2)Mach异常端口换出+信号处理Handler覆盖

和NSSetUncaughtExceptionHandler的情况类似,设置过的Mach异常端口和信号处理程序也有可能被干掉,导致无法捕获Crash事件。

这里尤其需要提一下:前面我们只说了UncaughtExceptionHandler被覆盖的情况,实际上signal的handler也会被覆盖。而如何检测信号绑定的回调的handler很少有文章提到。笔者经过思考探索,把突破口定位于POSIX层,从而找到了解决办法:(这里请允许我由衷的感叹一句:真理往往很简单,但是发现真理的过程却是艰难的。)

链接:http://www.cnblogs.com/lidabo/p/4581202.html
http://blog.csdn.net/u010944778/article/details/47375299

3)影响系统崩溃日志准确性
集成多个crash收集服务,可能会导致日志收集的不准确性升高。

1、由于进程内线程数组的变动,可能会导致系统日志中线程的Crashed 标签标记错位,可以搜索abort()等关键字排查系统日志的准确性。(该方法未尝试过,暂时未遇到出错情况)
2、因NSException而Crash,系统日志中的Last Exception Backtrace信息是完整准确的。即应用级异常不受影响。

5、 Xcode 如何调试 signal信号

关于signal信号的捕捉,在Xcode调试时,Debugger模式会先于我们的代码catch到所有的crash,所以需要直接从模拟器中进入程序才可以

如果想要在Xcode中调试怎么办?(经过探索,已经证明该方法有效,在xcode9中已验证可行)
Xcode屏蔽了signal的回调,我们需要在lldb中输入以下命令,signal的回调就可以进来了:
pro hand -p true -s false SIGABRT
注意:SIGABRT可以替换为你需要的任何signal类型,比如SIGSEGV


iOS app崩溃捕获_第4张图片
signal调试.png

参考:https://www.jianshu.com/p/133fd6f20563
转载注明出处:http://www.jianshu.com/p/b5304d3412e4

你可能感兴趣的:(iOS app崩溃捕获)