备用信号栈

上面这个方法可以监控到大部分的 Signal 异常，但是我们会发现如果遇到死循环这类的Crash，就没法监控了。原因是一般情况下，信号处理函数被调用时，内核会在进程的栈上为其创建一个栈帧。但这里就会有一个问题，如果之前栈的增长达到了栈的最大长度，或是栈没有达到最大长度但也比较接近，那么就会导致信号处理函数不能得到足够栈帧分配。

为了解决这个问题，我们需要设定一个可选的栈帧：

1. 申请一块内存空间作为可选的信号处理函数栈使用
2. 使用 sigaltstack 函数通知系统可选的信号处理栈帧的存在及其位置
3. 当使用 sigaction 函数建立一个信号处理函数时，通过指定 SA_ONSTACK 标志通知系统这个信号处理函数应该在可选的栈帧上面执行注册的信号处理函数

前面监听 Unix 信号的代码，改动一下：

void installSignalHandler() {
        stack_t ss;
    struct sigaction sa;
    struct timespec req, rem;
    long ret;

    ss.ss_flags = 0;
    ss.ss_size = SIGSTKSZ;
    ss.ss_sp = malloc(ss.ss_size);
    sigaltstack(&ss, NULL);

    memset(&sa, 0, sizeof(sa));
    sa.sa_handler = handleSignalException;
    sa.sa_flags = SA_ONSTACK;
    sigaction(SIGABRT, &sa, NULL);
}

调试 Signal 信号

有可能为了调试，你会在处理堆栈的地方打上断点，但是 Crash 发生后却没有命中。这是因为在Xcode调试时，Debugger模式会先于我们的代码catch到所有的crash，所以需要直接从模拟器中进入程序才可以。

如果想要在Xcode中调试，网上我找个方法。在lldb中输入以下命令：pro hand -p true -s false SIGABRT。注意:SIGABRT可以替换为你需要的任何signal类型，比如SIGSEGV。

image

但是...我自己试了并不成功，我仍然写出来供大家坐坐参考，说不定你们就可以了。

除此之外还有个办法就是使用控制台这个 app，可以在应用程序(Application)里面找到这个 app，打开后你可以看到各种 app 的输出。然后通过关键字找到你想要日志：

image

NSException

NSException 是应用级异常，是指 OC 代码运行过程由Objective-C 抛出的异常，基本上是代码运行过程中的逻辑错误。比如往 NSArray 中插入 nil 对象，或者用nil 初始化 NSURL 等。最简单区分一个异常是否 NSException 的方式是看这个异常能否被@trycatch 给捕获。

常见的 NSException 场景

• 非主线程刷新UI

• NSInvalidArgumentException
  非法参数异常(NSInvalidArgumentException)是 Objective – C 代码最常出现的错误，所以平时在写代码的时候，需要多加注意，加强对参数的检查，避免传入非法参数导致异常，其中尤以nil参数为甚。

• NSRangeException
  越界异常(NSRangeException)也是比较常出现的异常。

• NSGenericException
  NSGenericException这个异常最容易出现在foreach操作中，在for in循环中如果修改所遍历的数组，无论你是add或remove，都会出错 “for in”,它的内部遍历使用了类似 Iterator进行迭代遍历，一旦元素变动，之前的元素全部被失效，所以在foreach的循环当中，最好不要去进行元素的修改动作，若需要修改，循环改为for遍历，由于内部机制不同，不会产生修改后结果失效的问题。

• NSInternalInconsistencyException
  不一致导致出现的异常
  比如NSDictionary当做NSMutableDictionary来使用，从他们内部的机理来说，就会产生一些错误
  NSMutableDictionary *info = method return to NSDictionary type;
  [info setObject:@“sxm” forKey:@”name”];
  比如xib界面使用或者约束设置不当

• NSFileHandleOperationException
  处理文件时的一些异常，最常见的还是存储空间不足的问题，比如应用频繁的保存文档，缓存资料或者处理比较大的数据:
  所以在文件处理里，需要考虑到手机存储空间的问题。

• NSMallocException
  这也是内存不足的问题，无法分配足够的内存空间
  此外还有

• KVO Crash
  移除未注册的观察者
  重复移除观察者
  添加了观察者但是没有实现-observeValueForKeyPath:ofObject:change:context:方法
  添加移除keypath=nil
  添加移除observer=nil

• unrecognized selector send to instance

监听 NSException 异常

NSException的监听也十分简单:

void InstallUncaughtExceptionHandler(void) {
    NSSetUncaughtExceptionHandler( &handleUncaughtException );
}

void handleUncaughtException(NSException *exception) {
    NSString * crashInfo = [NSString stringWithFormat:@"yyyy Exception name：%@/nException reason：%@/nException stack：%@",[exception name], [exception reason], [exception callStackSymbols]];
    NSLog(@"%@", crashInfo);
}

需要注意的是，在监听处理的方法中，是无法直接采集错误到堆栈的。详情我同样会在下一篇的崩溃堆栈收集的文章中介绍。

C++ 异常

有朋友看到这里可能就会好奇，前面说了三种异常，为何这里又多出一种异常。实质上C++异常也可以通过 Mach 异常的方式处理。只是在细节处理上仍多有区别。

以下部分内容转载自文章:iOS/OSX Crash：捕捉异常，具体内容需要读者自行验证。

为什么要捕捉 C++异常

在OSX中，会通过对话框展示异常给用户，但在iOS中，只是重新抛出异常。系统在捕捉到C++异常后，如果能够将此C++异常转换为OC异常，则抛出OC异常处理机制；如果不能转换，则会立刻调用__cxa_throw重新抛出异常。

当系统在RunLoop捕捉到的C++异常时，此时的调用堆栈是异常发生时的堆栈，但当系统在不能转换为OC异常时调用__cxa_throw时，上层捕捉此再抛出的异常获取到的调用堆栈是RunLoop异常处理函数的堆栈，导致原始异常调用堆栈丢失。

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib          0x00007fff93ef8d46 __kill + 10
1   libsystem_c.dylib               0x00007fff89968df0 abort + 177
2   libc++abi.dylib                 0x00007fff8beb5a17 abort_message + 257
3   libc++abi.dylib                 0x00007fff8beb33c6 default_terminate() + 28
4   libobjc.A.dylib                 0x00007fff8a196887 _objc_terminate() + 111
5   libc++abi.dylib                 0x00007fff8beb33f5 safe_handler_caller(void (*)()) + 8
6   libc++abi.dylib                 0x00007fff8beb3450 std::terminate() + 16
7   libc++abi.dylib                 0x00007fff8beb45b7 __cxa_throw + 111
8   test                            0x0000000102999f3b main + 75
9   libdyld.dylib                   0x00007fff8e4ab7e1 start + 1

如何捕捉C++异常

为了获得C++异常的调用堆栈，我们需要模拟抛出NSException的过程并在此过程中保存调用堆栈。

1. 设置异常处理函数

   g_originalTerminateHandler = std::set_terminate(CPPExceptionTerminate);
   
   

   调用std::set_terminate设置新的全局终止处理函数并保存旧的函数。

2. 重写__cxa_throw

   void __cxa_throw(void* thrown_exception, std::type_info* tinfo, void (*dest)(void*))
   
   

   在异常发生时，会先进入此重写函数，应该先获取调用堆栈并存储；再调用原始的__cxa_throw函数。

3. 异常处理函数

   __cxa_throw往后执行，进入set_terminate设置的异常处理函数。判断如果检测是OC异常，则什么也不做，让OC异常机制处理；否则获取异常信息。

不同类型的异常之间的关系

在前面，我们讲了几种异常类型及其细节。但是他们之间的关系我们还了解甚少。下面我就来讲讲不同异常之间可能存在的转换关系，以及优先顺序等。

异常处理的顺序

首先，我们看一下下图，这个图很重要

image

我大致总结一下：

1. 如果是 NSException 类型的异常

   先看 app 是否 trycatch 了；再看有没有实现 NSSetUncaughtExceptionHandler；最后如果都没处理，则调用 c 的 abort()，kernal 针对 app 发出 _pthread_kill 的信号，转为 Mach 异常。

2. 如果是 Mach 异常

   如果 app 处理了 Mach 异常则进入处理流程；否则 mach 异常会被转为 Unix/BSD signal 信号，并进入 Signal 的处理流程。

简单的说就是：NSException->Mach->Signal

不同类型异常的关系和处理决策

首先要明确的一点是，Mach异常和UNIX信号都可以被捕获，他们也几乎一一对应。那为什么几乎所有 Crash 监控框架都会捕捉 Mach 异常、Unix 信号以及 NSException 呢？

Mach 异常 和 Unix 信号

所有Mach异常未处理，它将在host层被ux_exception转换为相应的Unix信号，并通过threadsignal将信号投递到出错的线程。所以其实所有我们看到的 Unix信号异常，都是从 Mach 传过来的，只是在 Mach 没有catch，所以转成Unix给我们处理。比如 Bad Access。

1. 既然 Unix 信号都是由 Mach Exception 转化的，为啥还要转Unix 信号呢，直接传 Mach 的异常不就行了？
   这是为了兼容更为流行的POSIX标准，BSD在Mach异常机制之上构建的UNIX信号处理机制。
2. 既然 Mach Exception 能转化为 Signal 信号，Signal 信号监听也更简单，为什么不只监听 Signal 信号？
   不是所有的 "Mach异常” 类型都映射到了 “UNIX信号”。 如 EXC_GUARD 。在苹果开源的 xnu 源码中可以看到这点。
3. 为什么优先监听 Mach Exception？
   这是因为 Mach 异常会更早的抛出来，而且如果Mach异常的handler让程序exit了，那么Unix信号就永远不会到达这个进程了。

为什么不能只监听 Mach Exception？

网上所说的原因都是因为 EXC_CRASH 不能通过 Mach 监控来抓捕。那为什么不能呢？网上我所有能找到的中文资料，都是如此解释（来源开源项目 plcrashreporter)：

We still need to use signal handlers to catch SIGABRT in-process. The kernel sends an EXC_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.

大致意思是说我们是在进程中监听 Mach Exception，在 EXC_Crash 发生的时候，会发生进程死锁。但是我一直没明白为啥会死锁。于是我又搜索了一下外文资料。发现有一篇文章大量的讲述了EXC_Crash.

If you’re messing with EXC_CRASH, you probably know that a major drawback of this scheme is that it can only respond to crashes that originated as genuine hardware traps. abort() and all of the things that wind up calling abort() are not, they’re generated entirely in software. This is important for a crash reporter because lots of interesting crashes arise through this mechanism, such as assertion failures and runtime (C++ and Objective-C) exceptions. abort() is implemented in Libc-825.26/stdlib/FreeBSD/abort.c abort, and it raises SIGABRT all on its own, without ever triggering a hardware trap. That means that your program can catch these crashes in-process via the POSIX signal interface, but because it was never a Mach exception to begin with, there’s no opportunity to catch one.

This is where EXC_CRASH comes in. EXC_CRASH is a new (as of Mac OS X 10.5) exception type that’s only generated in one place: when a process is dying an abnormal death. In xnu-2050.24.15/bsd/kern/kern_exit.c proc_prepareexit, the logic says that if the process is exiting due to a signal that’s considered a crash (one that might generate a “ core” file, identified by the presence of SA_CORE in xnu-2050.24.15/bsd/sys/signalvar.h sigprop), an EXC_CRASH Mach exception will be raised for the task. Along with several other signals, the SIGILL, SIGSEGV, SIGBUS, and SIGABRT examples above are all core-generating, so they qualify for this treatment. By the time a process is exiting due to an unhandled signal, it’s a goner. It’s not going to be scheduled any more. That includes any Mach exception handler that was running on a thread in the process. This is why you can’t catch EXC_CRASHexceptions in the process itself: by the time an EXC_CRASH is generated, your process is no longer running. Indeed, in the bug report, you can see the abort() as an “upstream” caller of in-kernel process teardown code, passing through proc_prepareexit, exception_triage, and ultimately getting blocked waiting for a response to mach_exception_raise that will never come.

我提炼一下上文的要点：

1. EXC_Crash 表示进程是非正常退出。
2. 当 EXC_Crash 发生的时候，这意味着进程即将被强杀，任何其他任务都不会被执行，所以Mach Exception Handler 不会执行。
3. 类似 abort()的方法只会触发 signal 信号，根本不会触发hardware trap。

所以，我认为我们需要监听 Signal 的原因是 EXC_Crash 根本不能通过 Mach 监控来捕捉，和死锁无关。即便是和死锁有关，类似 abort()的场景也必须使用 Signal 监听。

Mach Exception 和 Signal 的转换关系

image

上图是网络上找来的一个对应关系，但我觉得这个对应关系只适合在 Mach Exception 处理的时候使用。在 Signal 处理的时候，建议使用如下的对应关系：

关于 Mach 和 Signal 的说明，还可以参考一下官方文档

为何要实现 NSException 监听

按照我们前面所说，通过 Mach/Signal 的方式我们已经可以监听绝大部分崩溃场景了，那为何我们还要实现NSException 监听呢？原因就是未被try catch的NSException会发出kill或pthread_kill信号-> Mach异常-> Unix信号（SIGABRT）,但是SIGABRT在处理收集信息时，获取当前堆栈时获取不到，所以采用`NSSetUncaughtExceptionHandler。具体如何获取堆栈我们会在下一篇文章讲解

捕捉 Swift 崩溃

一开始我以为 Swift 下的 exception 的处理过程和 NSException 类似，但实践后发现根本不是。

• swift通常都是通过对应的signal来捕获crash。对于swift的崩溃捕获，Apple的文档中有描述说需要通过SIGTRAP信号捕获强转失败，及非可选的nil值导致的崩溃.具体描述如下：

  Trace Trap[EXC_BREAKPOINT // SIGTRAP]
  类似于异常退出，此异常旨在使附加的调试器有机会在其执行中的特定点中断进程。您可以使用该__builtin_trap()函数从您自己的代码触发此异常。如果没有附加调试器，则该过程将终止并生成崩溃报告。
  较低级的库（例如，libdispatch）会在遇到致命错误时捕获进程。有关错误的其他信息可以在崩溃报告的“ 附加诊断信息”部分或设备的控制台中找到。

  如果在运行时遇到意外情况，Swift代码将以此异常类型终止，例如：
  1.具有nil值的非可选类型
  2.一个失败的强制类型转换

• 对于swift还有一种崩溃需要捕获(Intel处理器,我认为应该是指在模拟器上的崩溃)，为保险起见，也需要将信号SIGILL进行注册，Apple同样对其中做了描述

  Illegal Instruction[EXC_BAD_INSTRUCTION // SIGILL]
  该过程尝试执行非法或未定义的指令。该过程可能尝试通过错误配置的函数指针跳转到无效地址。
  在Intel处理器上，ud2操作码引起EXC_BAD_INSTRUCTION异常，但通常用于进程调试目的。如果在运行时遇到意外情况，Intel处理器上的Swift代码将以此异常类型终止。有关详细信息，请参阅Trace Trap。

解除监听

细心的朋友可能会注意到前面监控 Crash 的代码都包括了类似一下的代码：

NSSetUncaughtExceptionHandler(NULL);
signal(SIGHUP, SIG_DFL);

这是因为:1.保证一个 Crash 只会被一个 Handler 处理，避免多次处理；2.防止可能出现死锁导致应用不能退出。

多监控框架的共存

尽管从技术上讲多 Crash 监控框架共存是可能的。但是我并不喜欢这么做。当发生 Crash 的时候，app 已经处于一个不稳定的状态，过长的 Crash 处理链条会导致崩溃堆栈不准确，并且在处理过程中引入新的 Crash。如果你非要在崩溃的时候处理些额外的工作，大部分 Crash 监控框架，如 KSCrash 等，都提供了事件回调供你使用。

如果你们对这一块还是很感兴趣，可以参考下这篇文章：iOS/OSX Crash：捕捉异常

总结

虽然本篇总结的是 iOS 下的 Crash 监听，但由于 iOS/Mac OS 都是基于 Unix 的，所以其实很多内容是跨平台，在写本文的过程中我也找寻了很多 C 语言下的解决方案。

我尽量将我在学习这个知识所遇到的所有困惑以及收获都分享在这篇文章。但是依然可能有些遗漏和错误，欢迎各位指正。而撰写此文的过程中，有大量的内容整理自其他文章，其目的是尽可能在一篇文章完整的讲述相关内容。

最后，如果此文对你有帮助，不求赞赏，只求大家轻轻一个点赞。

iOS开发

作者：felix9
链接：https://www.jianshu.com/p/3f6775c02257
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。