原文鏈接
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