iOS Swift Crash的捕获

iOS Swift Crash的捕获

crash捕获介绍

• 如果对crash捕获不太了解，可以先参考这篇文章,本文进行Mach异常+Unix信号方式捕获crash。

• NSException一般只在OC当中被捕获，一般情况下在捕获NSException异常后同时也会捕获到一个对应的signal异常。但如果你使用的是纯swift开发，如下代码并不会捕获相关的crash

    NSSetUncaughtExceptionHandler(UncaughtExceptionHandler)
  

swift崩溃捕获

• 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捕获实现代码参考

    //对于OC的exception采取如下方式捕获
    NSSetUncaughtExceptionHandler(UncaughtExceptionHandler)
    //对于Swift则捕获相关signa，一般来说如下几种已经能够捕获大部分crash。(其中SIGTRAP一定要捕获,swift大量的crash都会通过它）
     signal(SIGABRT, SignalExceptionHandler)
    signal(SIGSEGV, SignalExceptionHandler)
    signal(SIGBUS, SignalExceptionHandler)
    signal(SIGTRAP, SignalExceptionHandler)
    signal(SIGILL, SignalExceptionHandler)

获取Slide Address

通过获取到偏移量地址Slide Address和错误信息的内存地址基本即可定位错误，错误信息的内存地址在捕获的crash信息中会体现，Slide Address则需要我们自己获取，通过调用如下C方法我们可以获取到偏移量地址，这里通过OC文件来调用C方法。方法如下:

//MARK: - 获取偏移量地址
long  calculate(void){
long slide = 0;
for (uint32_t i = 0; i < _dyld_image_count(); i++) {
    if (_dyld_get_image_header(i)->filetype == MH_EXECUTE) {
        slide = _dyld_get_image_vmaddr_slide(i);
        break;
    }
}
return slide;
}

crash分析介绍

• 如果想要定位错误，通过拿到Slide Address和错误信息的内存地址即可定位(实际上错误信息地址可以通过Slide Address加上偏移量获得)
• 拿到Slide Address和错误信息的内存地址后我们可以通过一个开源工具dSYMTools直接定位到我们想要的信息。感谢作者的贡献，让我们更加方便快捷的分析问题。
• dSYMTools 需要传入.xcarchive文件，你可以通过Xcode找到你对应提交版本的.xcarchive。你也可以在提交前保留对应的.xcarchive，以供万一产生crash分析使用,这里的.xcarchive一定要与产生crash信息的版本对应，否则无法定位到崩溃信息

具体分析

• 当自己捕获NSException Crash并上传到服务器之后，正常crash大概会显示信息如下，我们大概能够知道是由于数组溢出导致的崩溃。

    Stack:
    slideAdress:0xec000
    name:NSRangeException 
    reason:Optional("*** -[__NSArray0 objectAtIndex:]: index 66         beyond bounds for empty NSArray") 
    0   CoreFoundation                      0x0000000181646ff0      <redacted> + 148
    1   libobjc.A.dylib                     0x00000001800a8538      objc_exception_throw + 56
    2   CoreFoundation                      0x00000001815b2eb8      <redacted> + 0
    3   CrashManager                        0x00000001000f3000      CrashManager + 28672
    4   UIKit                               0x00000001877ab0ec      <redacted> + 96
    5   UIKit                               0x00000001877ab06c      <redacted> + 80
    6   UIKit                               0x00000001877955e0      <redacted> + 440
    7   UIKit                               0x00000001877aa950      <redacted> + 576
    8   UIKit                               0x00000001877aa46c      <redacted> + 2480
    9   UIKit                               0x00000001877a5804      <redacted> + 3192
    10  UIKit                               0x0000000187776418      <redacted> + 340
    11  UIKit                               0x0000000187f6ff64      <redacted> + 2400
    12  UIKit                               0x0000000187f6a6c0      <redacted> + 4268
    13  UIKit                               0x0000000187f6aaec      <redacted> + 148
    14  CoreFoundation                      0x00000001815f5424      <redacted> + 24
    15  CoreFoundation                      0x00000001815f4d94      <redacted> + 540
    16  CoreFoundation                      0x00000001815f29a0      <redacted> + 744
    17  CoreFoundation                      0x0000000181522d94      CFRunLoopRunSpecific + 424
    18  GraphicsServices                    0x0000000182f8c074      GSEventRunModal + 100
    19  UIKit                               0x00000001877db130      UIApplicationMain + 208
    20  CrashManager                        0x00000001000f139c      CrashManager + 21404
    21  libdyld.dylib                       0x000000018053159c <redacted> + 4 
  

  如上所示，slideAdress我们已经通过程序获取，这里是0xec000，由上往下找，我们可以看到3 CrashManager 0x00000001000f3000 CrashManager + 28672出现了CrashManager信息，那么0x00000001000f3000则有可能为我们想要定位的错误信息地址。将我们得到数据带入工具可清晰定位到错误：
  

  
  

  NSException错误信息.png

• 如果捕获到的Signal Crash，可能crash显示的信息大概会如下：

    Stack:
    slideAdress:0xa4000
    0   CrashManager                        0x00000001000a8f10      CrashManager + 20240
    1   CrashManager                        0x00000001000a9024      CrashManager + 20516
    2   libsystem_platform.dylib            0x000000018070530c      _sigtramp + 36
    3   CrashManager                        0x00000001000ab1bc CrashManager + 29116
    4   CrashManager                        0x00000001000aaa64 CrashManager + 27236
    5   UIKit                               0x00000001877ab0ec <redacted> + 96
    6   UIKit                               0x00000001877ab06c <redacted> + 80
    7   UIKit                               0x00000001877955e0 <redacted> + 440
    8   UIKit                               0x00000001877aa950 <redacted> + 576
    9   UIKit                               0x00000001877aa46c <redacted> + 2480
    10  UIKit                               0x00000001877a5804 <redacted> + 3192
    11  UIKit                               0x0000000187776418 <redacted> + 340
    12  UIKit                               0x0000000187f6ff64 <redacted> + 2400
    13  UIKit                               0x0000000187f6a6c0 <redacted> + 4268
    14  UIKit                               0x0000000187f6aaec <redacted> + 148
    15  CoreFoundation                      0x00000001815f5424 <redacted> + 24
    16  CoreFoundation                      0x00000001815f4d94 <redacted> + 540
    17  CoreFoundation                      0x00000001815f29a0 <redacted> + 744
    18  CoreFoundation                      0x0000000181522d94 CFRunLoopRunSpecific + 424
    19  GraphicsServices                    0x0000000182f8c074 GSEventRunModal + 100
    20  UIKit                               0x00000001877db130 UIApplicationMain + 208
    21  CrashManager                        0x00000001000a939c CrashManager + 21404
    22  libdyld.dylib                       0x000000018053159c <redacted> +
  

一般我们无法从signal产生的这些信息中直观获取到crash产生的原因，这里崩溃的地址我们一般优先选择_sigtramp后第一条有我们程序信息的地址，所以这里将slideAdress：0xa4000和可能的错误信息地址0x00000001000ab1bc代入：

signalCrash.png

注意事项

• 如果你使用工具解析后得到的信息是类似于这样的_hidden#30_ (in libswiftObjectiveC.dylib) (__hidden#70_:0),那么极有可能是因为你提交版本的时候勾选了BitCode，勾选了Bitcode之后,用户安装的二进制文件是苹果服务器经过优化后生成的,其对应的调试符号信息丢失了,所以你看到的全部是类似于__hidden#70_:0这样的信息，所以也无法通过还原奔溃现场找原因了.如果你如果你不太理解BitCode,可以参考这篇BitCode介绍和这篇讨论
• 如果你使用模拟器，那么由于本身绑定相关dSYM文件，你获取到的crash信息中可能不是错误地址而是很明显的相关错误信息，这不在本文讨论范围内，毕竟在调试过程中获取崩溃信息相对容易，本文阐述的是你的应用已经提交后捕获和分析用户使用过程中产生的crash

资源支持

这是一个完整的Demo,本篇文章所阐述的内容在Demo中都有体现，你可以直接使用Demo中的模块完成Crash捕获，也可以参考Demo阅读本文，相信可以更快理解，如果对你有帮助，给个star呗。
crash捕获参考文档连接