<译>TN2151 理解分析系统crash reports

原文链接

https://developer.apple.com/library/content/technotes/tn2151/_index.html

当一个系统崩溃的时候，一个系统crash report就会被创建。它非常有利于理解到底什么导致了这个崩溃。 这个文档包含了 如何符号化，理解和翻译这些崩溃报告。

介绍

当一个系统崩溃的时候。一个crash report 被生成 并同时储存在设备里。Crash report 描述了当应用终结的时候的条件。在大多情况下包含了所有执行的进程的回溯.并且典型的

Symbolicating Crash Reports 符号化Crash Report

1 当编译器翻译你的源码到机器码的时候，它同时生成了映射每个二进制机器指令回到源代码行数的 debug 符号表。依赖于调试信息格式Debug Infomation Format的建造设置，这些调试符号被储存在了二进制或者储存在了一同生成的调试符号表（dSYM，debug Symbol）文件中。默认情况下， 对于一个应用的调试模式创建，储存调试符号表在编译的二进制文件中。而发布的应用创建储存这些dSYM到了一个共同生成的dSYM文件用来减少二进制文件的大小

2 当你存档一个应用用来发布的时候，xcode会聚集应用的二进制文件和。dSYM文件。同时储存他们在你的home文件夹下。你可以找到你归档的应用在 xcode 的组织者（Organizer） ，“Archived”部分。

3 如果你通过APP Store 发布你的应用，或者用Test Flight 进行一项测试。你将会被给予一个选择——是否包含dSYM文件档上传你的archive到 Itunes Connect. 在提交的对话中。选择 “Include app symbols for your application.”上传你的 dSYM 文件是收到 TestFlight 用户和选择分享诊断数据的消费者的crash reports的条件。 

4 当你的应用crash的时候，没有被符号化的crash report 会被创造并且储存到设备中。

BitCode

字节码 Bitcode  是一个编译程序的中间表示。当你一个允许字节码打包应用的时候，编译器产生包含字节码而不是机器码的二进制文件。一旦二进制被上传到app store，这些字节码被编译成机器码。APP store可能再次编译这些字节码，为了利用未来编译起改进而不需要你做任何行为。

因为最终的编译二进制文件的操作发生在App Store,所以你的机器将不会包含 dSYM 文件。尽管一个dSYM 文件被你archive你的应用的生产出来 这个只是为了字节码 ，并不能被用来符号化 crash reports. App store制作的由字节码编译dSYM 文件允许你下载。从Xcode或者从Itunes Connect的网站。你必须下载这些dSYM文件。以用来符号化crash report 接受到App Review或者从用户

Exception Information 异常信息

这个列表列出了Mach 异常类型和 相关的能提供信息。不是所有的领域都会在每次崩溃报告中展示出来

Listing 5 一个崩溃报告的异常符号部分的摘要，生成于一个进程被终止于一个没有被捕获的 OC异常

Exception Type : EXC_carsh(SIGABRT)

Listing 6  一个进程被终止产生的崩溃报告摘要因为他是一个NULL指针。

Exception Type : EXC_BAD_ACCESS (SIGSEGV)

Exception Codes： 处理器关于异常的特殊信息被编译成一个或者更多64bit的十六进制数字。通常而言，此字段将不会呈现因为崩溃reporter解析这个异常代码，以在其他字段中将其作为人性化可读的描述。

Exception Subtype:异常代码里人性化可读的名字

Exception Message:从异常代码中提取的额外的 人性化可读的信息

Exception Note：不是特定于一个异常类型的其他信息。如果这个字段包含 SIMULATED (this is NOT a crash) 之后这个进程不会崩溃，但是被系统的请求杀死了，尤其是看门狗

Termination Reason 退出进程终止时指定的退出原因信息。关键的系统要素，

Bad Memory Access EXC_BAD_ACCESS SIGSEGV SIGBUS

这个进程尝试去方法为一个不正确的内存或者试图去进入被保护的内存。这个异常 Subtype 字段包含一个 kern_return_t 描述错误和错误访问的内存地址

这有些建议用来先解决

如果 objc_msgSend 或者 objc_relese 接近 堆栈回溯顶部 。这个进程可能尝试和一个已经释放的对象通信。你应该用Zombies instrument

如果 gpus_returnNOtPermittedKillCilent 接近顶部。这个进程被杀死因为在后台用OpenGL ES或者Metal渲染

在Address sanitizer 允许的的情况向运行你的程序。这个

异常的退出 EXC_Crash //SIGABRT

这个进程异常退出。最可能的原因是没有不活的 Object-c/c++ 异常并且调用了 abort();

如果应用程式扩充功能需要太多时间来初始化（看门狗终止） 应用程式扩展功能就会以这个例外类型终止。如果一个扩充功能被誉为启动的时候吊起，这个异常子类型将会被 LaunCh——hang 因为扩充类型没有一个main函数。任何花费的初始化时间都发生在扩展和依赖库中的静态构造函数和加载方法中。你应该尽可能多的推迟这项工作。

跟踪陷阱 EXC_BREAKPOINT // SIGTRAP

与异常退出类似 这个异常旨在为附加的调试器提供在其执行的特定点处中断进程的机会。可以使用__builtin_trap ()函数从你自己的代码中触发此异常。如果没有附加调试器，则该过程终止，并生成崩溃报告。

低等级的库会在遇到一个致命错误的时候中断这个进程。关于这个错误额外的信息可以在 额外的诊断信息部分找到 这个崩溃的报告。或者在设备的控制台。

如果出现了如下的运行时环境异常的环境swift代码将会被这个异常的类型终止。

指令异常 EXC_BAD_INSTRUCTION //SIGILL

这个进程尝试去执行非法或者未定义的指令。 改进程可能视图通过错误配置的函数指针跳转到无效地址。在Intel处理器上，ud2操作码导致EXC_BAD_INSTRUCTION异常，但通常用户陷阱该进程以进行调试。如果在运行时遇到意外情况，Intel处理器上的Swift代码讲义此异常类型终止。

保护资源违规 EXC_GUARD

这个进程在一块受保护的资源违规操作。系统的库可能将某些文件描述符标记为防护，之后对这些描述符的正常错做将处罚EXC_GUARD异常(当它希望对这些文件描述符进行操作时，系统使用特殊的保护私有API).这有助于您快速跟踪问题，例如关闭已由系统库打开的文件描述符。

资源受限 EXC_RESOURCE

这个进程超过资源消耗限制。这是来自操作系统的通知，进程正在使用太多的资源。确切的字段将在子字段中显示。

异常子类型WAKEUPS指示进程中的线程被唤醒太多次，这迫使CPU非常频繁地唤醒并消耗电池寿命。

其他异常类型

如果你收到一个没有命名的异常类型，将会以16进制打印。如果你收到一个这种异常报告，直接看异常代码 来看更多信息。

 堆栈帧的执行函数所在的二进制文件的名称

对于零帧，执行停止时执行的机器指令的地址。对于剩余的堆栈帧，当控制返回堆栈帧时，将执行的机器指令的地址

在符号崩溃报告中，函数在堆栈框架中的方法名称。

OC中的异常用户只是在运行时检测到的编程错误。例如控制具有超出索引的数据 尝试突变不可变对象，不识闲协议的所需方法，或发送消息接收机不能被识别。

注意：发送个一个事先释放的对象可能会引发 NSInvalidArgumentException而不是破坏程序的内存访问。当在被释放对象先前占用的内存中中充分分配对象，

如果异常没有被捕获，它被一个称谓捕获异常处理程序的函数拦截，默认为捕获异常处理程序将异常消息记录到设备的控制台，然后终止进程。只有异常回溯被写入到最后一个坏吃货回溯部分下生成的崩溃报告。崩溃报告中胜率了异常消息。如果您收到最后异常backtrace的崩溃报告，您应该从原设备获取控制台机制，以更好地了解导致异常的条件。

本节列出在终止时在进程中加载的二进制映像。

第一行 在进程中二进制地址空间的位置

二进制包名称 

二进制映像的架构。一个二进制包含多个切片。One