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异常是指最底层的内核级异常，被定义在 <mach/exception_types.h>下 。
每个thread，task，host都有一个异常端口数组，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信号，并投递到出错的线程。
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内核编程，需要对内核有一定了解
内核crash收集的流程.png
具体代码看下图：
代码实现.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 <mach/task.h>
#include <mach/mach_init.h>
#include <mach/mach_port.h>
//+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 an
EXC_CRASHmach 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，需要特殊处理，需要去获取它的reason，name，callStackSymbols信息才能确定出问题的程序位置。因为出现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
signal调试.png
参考：https://www.jianshu.com/p/133fd6f20563
转载注明出处：http://www.jianshu.com/p/b5304d3412e4
网友评论