崩潰報告crash分析
每一個崩潰報告的每個部分都有崩潰原因的信息,一般分為6部分
1 報告頭 （Header ）
2 異常代碼(Exception Codes)
3 應(yīng)用詳情(Application Specific Information)
- 回溯(Backtrace)
- 線程狀態(tài)(Thread State)
- 二進(jìn)制映像(Binary Images)
Header
標(biāo)頭：開頭部分描述了崩潰發(fā)生的環(huán)境
Incident Identifier： 報告的唯一標(biāo)識符，兩份報告決不會共享同一個事件標(biāo)識符
CrashReporter Key：每個設(shè)備的匿名標(biāo)識符，來自同一設(shè)備的兩個報告將包含相同的值
Hardware Model：運(yùn)行該應(yīng)用程序的特定設(shè)備型號
Process：崩潰的進(jìn)程的可執(zhí)行文件名稱
Path：可執(zhí)行文件在磁盤上的位置。macOS用占位符值替換了用戶可識別的路徑組件，以保護(hù)隱私
AppStoreTools：Xcode的版本
AppVariant：通過應(yīng)用程序細(xì)化產(chǎn)生的應(yīng)用程序的特定變體
Code Type：崩潰的進(jìn)程的CPU體系結(jié)構(gòu)。ARM-64，ARM，X86-64，或X86
Parent Process：啟動崩潰進(jìn)程的進(jìn)程的名稱和進(jìn)程ID
Coalition：包含應(yīng)用程序的名稱
Date/Time ：崩潰的日期和時間
Launch Time：應(yīng)用啟動的日期和時間
OS Version：發(fā)生崩潰的操作系統(tǒng)版本
異常信息（Exception Codes）
該部分告訴app過程如何終止
Exception Type：終止進(jìn)程的Mach異常的名稱，以及括號中相應(yīng)終止信號的名稱Unix
Exception Subtype：異常代碼描述
Exception Note：并非特定于一種異常類型的其他信息。如果包含此字段，則崩潰不是由硬件陷阱引起的，要么是由于進(jìn)程已由操作系統(tǒng)明確終止，要么是由于進(jìn)程被稱為。如果此字段包含，則進(jìn)程不會崩潰，但是操作系統(tǒng)隨后可能已請求終止進(jìn)程。如果此字段包含，則該過程不會終止，因?yàn)閯?chuàng)建崩潰報告的問題不是致命的
VM Region Info：區(qū)域信息
Termination Signal：終止信號
Termination Reason：操作系統(tǒng)終止進(jìn)程時指定的退出原因信息
Triggered by Thread或Crashed Thread：引發(fā)異常的線程
Exception Type
異常類型(Exception Type) 有以下幾種：
Bad Memory Access（壞內(nèi)存訪問） [EXC_BAD_ACCESS // SIGSEGV // SIGBUS],這種類型的 Exception 是最為常見的 Crash ，通常是由于訪問了無效的內(nèi)存導(dǎo)致的。
SIGSEGV：訪問了無效地址，沒有物理內(nèi)存對應(yīng)該地址，通常由于重復(fù)釋放對象導(dǎo)致。
SIGBUS：總線錯誤，與 SIGSEGV 不同的是，SIGBUS 訪問的是有效地址，但總線訪問異常，通常是訪問了未對齊的數(shù)據(jù)。
SEGV：代表無效內(nèi)存地址，比如空指針、未初始化指針、棧溢出等。Abnormal Exit （異常退出） [EXC_CRASH // SIGABRT]
SIGABRT：收到Abort信號退出，通常Foundation庫中的容器為了保護(hù)狀態(tài)正常會做一些檢測，例如插入nil到數(shù)組或字典中等會遇到此類錯誤。（常見的是再網(wǎng)絡(luò)請求時發(fā)生）。其它異常類型,有些異常類型沒有被命名，以16進(jìn)制數(shù)字表示。
0xbaaaaaad：意味著該Crash log并非一個真正的Crash，它僅僅只是包含了整個系統(tǒng)某一時刻的運(yùn)行狀態(tài)，由用戶同時按[Home鍵]和音量鍵觸發(fā)。
0xbad22222：當(dāng)VoIP程序在后臺太過頻繁的激活時，系統(tǒng)可能會終止此類程序。
0x8badf00d：程序啟動或者恢復(fù)時間過長被watch dog終止。
0xc00010ff：程序執(zhí)行大量耗費(fèi)CPU和GPU的運(yùn)算，導(dǎo)致設(shè)備過熱，觸發(fā)系統(tǒng)過熱保護(hù)被系統(tǒng)終止。
0xdead10cc：程序退到后臺時還占用[系統(tǒng)資源]（如通訊錄）被系統(tǒng)終止。
0xdeadfa11：程序無響應(yīng)用戶強(qiáng)制退出。當(dāng)用戶長按電源鍵，直到屏幕出現(xiàn)關(guān)機(jī)確認(rèn)畫面后再長按[Home鍵]，將強(qiáng)制退出應(yīng)用。我們可以合理認(rèn)為用戶這么做的原因是應(yīng)用程序沒有響應(yīng)。
應(yīng)用詳情(Application Specific Information)
有些Crash出現(xiàn)時，會產(chǎn)生額外的信息，這些信息能幫助用戶更好地了解應(yīng)用程序終止時的運(yùn)行環(huán)境。
回溯(Backtrace)
每個回溯的第一行列出了線程號和線程名。Xcode中的崩潰管理器提供的崩潰報告不包含線程名稱。
在線程號之后，回溯的每一行代表回溯中的堆棧
-
2:堆棧幀號，堆棧幀按調(diào)用順序排列 -
xxx:正在執(zhí)行的函數(shù)的二進(jìn)制文件的名稱 -
0x0000000107fc24a4:正在執(zhí)行的機(jī)器指令的地址 -
[AFURLSessionManagerTaskDelegate URLSession:task:didCompleteWithError:]:在完全符號化的崩潰報告中，正在執(zhí)行的函數(shù)的名稱 -
62104740:當(dāng)前指令的字節(jié)偏移量。 -
AFURLSessionManager.m: 183:包含代碼的文件名和行號
線程狀態(tài)(Thread State)
這部分列出了發(fā)生Crash的線程的狀態(tài)，即寄存器和寄存器的值
二進(jìn)制映像(Binary Images)
此列表包含上一示例中的組件：
-
0x104324000 - 0x108707fff進(jìn)程中二進(jìn)制映像的地址范圍。第一個地址是二進(jìn)制文件的加載地址 -
xxx二進(jìn)制名稱 -
arm64CPU -
2xxxxxxxxxxxxxxxxxxxx3唯一標(biāo)識二進(jìn)制映像的構(gòu)建UUID。當(dāng)符號崩潰報告時，使用此值來找到相應(yīng)的文件 -
/var/containers/Bundle/Application/..磁盤上二進(jìn)制文件的路徑
