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捕获参考文档连接
- 本文谢绝转载，如需转载请联系我授权，原创不易，还请理解。
网友评论