如何查看crash日志

頭部信息

Incident Identifier: B6FD1E8E-B39F-430B-ADDE-FC3A45ED368C

CrashReporter Key: f04e68ec62d3c66057628c9ba9839e30d55937dc

Hardware Model: iPad6,8

Process: TheElements [303]

Path: /private/var/containers/Bundle/Application/888C1FA2-3666-4AE2-9E8E-62E2F787DEC1/TheElements.app/TheElements

Identifier: com.example.apple-samplecode.TheElements

Version: 1.12

Code Type: ARM-64 (Native)

Role: Foreground

Parent Process: launchd [1]

Coalition: com.example.apple-samplecode.TheElements [402]

Date/Time: 2016-08-22 10:43:07.5806 -0700

Launch Time: 2016-08-22 10:43:01.0293 -0700

OS Version: iPhone OS 10.0 (14A5345a)

Report Version: 104

Incident Identifier報(bào)告的唯一標(biāo)識(shí)符鞍爱。 兩份報(bào)告決不會(huì)共享同一個(gè)事件標(biāo)識(shí)符

CrashReporter Key匿名的每個(gè)設(shè)備標(biāo)識(shí)符腕让。 來(lái)自同一設(shè)備的兩個(gè)報(bào)告將包含相同的值驮吱。

Beta Identifier崩潰的應(yīng)用程序的設(shè)備和供應(yīng)商的組合的唯一標(biāo)識(shí)符。 兩個(gè)來(lái)自同一供應(yīng)商和同一設(shè)備的應(yīng)用程序報(bào)告將包含相同的值。 該字段僅出現(xiàn)在為通過(guò)TestFlight分發(fā)的應(yīng)用程序生成的崩潰報(bào)告中，并替換CrashReporter Key字段。

Process崩潰的進(jìn)程的可執(zhí)行文件名稱灸叼。 這與應(yīng)用程序的信息屬性列表中的CFBundleExecutable鍵的值相匹配神汹。

Version崩潰的進(jìn)程的版本。 該字段的值是崩潰的應(yīng)用程序的CFBundleVersion和CFBundleVersionString的串聯(lián)古今。

Code Type:崩潰過(guò)程的目標(biāo)體系結(jié)構(gòu)屁魏。 這將是ARM-64，ARM捉腥，x86-64或x86之一氓拼。

Role:終止時(shí)分配給進(jìn)程的task_role。

OS Version操作系統(tǒng)版本但狭，包括發(fā)生崩潰的內(nèi)部版本號(hào)

異常信息

不要與Objective-C / C ++異撑混淆（盡管其中之一可能是崩潰的原因），本節(jié)列出了Mach異常類型以及提供關(guān)于崩潰性質(zhì)信息的相關(guān)字段立磁。 并非所有的字段都會(huì)出現(xiàn)在每個(gè)崩潰報(bào)告中

以下是幾種情況

Exception Type: EXC_CRASH (SIGABRT)

Exception Codes: 0x0000000000000000, 0x0000000000000000

Exception Note: EXC_CORPSE_NOTIFY

Triggered by Thread: 0

1 由于未被捕獲的Objective-C異常而終止進(jìn)程時(shí)生成的崩潰報(bào)告中異常代碼部分的摘錄呈队。

Exception Type: EXC_BAD_ACCESS (SIGSEGV)

Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000

Termination Signal: Segmentation fault: 11

Termination Reason: Namespace SIGNAL, Code 0xb

Terminating Process: exc handler [0]

Triggered by Thread: 0

2 當(dāng)一個(gè)進(jìn)程被終止，因?yàn)樗獬艘粋€(gè)空指針的引用而生成的崩潰報(bào)告中的異常代碼部分的摘錄

以下介紹此種情況中可能出現(xiàn)的字段的解釋唱歧。

Exception Codes有關(guān)異常的處理器特定信息編碼成一個(gè)或多個(gè)64位十六進(jìn)制數(shù)字宪摧。 通常情況下，這個(gè)字段不會(huì)出現(xiàn)颅崩，因?yàn)镃rash Reporter解析異常代碼几于，將它們作為其他字段中的人類可讀描述。

Exception Subtype異常代碼的可讀名稱

Exception Message從異常代碼中提取的其他可讀信息沿后。

Exception Note:其他信息不是特定于一種例外類型沿彭。 如果這個(gè)字段包含SIMULATED（這不是崩潰），那么進(jìn)程沒(méi)有崩潰尖滚，但是在系統(tǒng)的請(qǐng)求下喉刘，通常是看門(mén)狗。

Termination Reason退出進(jìn)程終止時(shí)指定的原因信息漆弄。 進(jìn)程內(nèi)外的關(guān)鍵系統(tǒng)組件將在遇到致命錯(cuò)誤（例如睦裳，錯(cuò)誤的代碼簽名，缺少的相關(guān)庫(kù)或訪問(wèn)隱私敏感信息而沒(méi)有正確授權(quán)）時(shí)終止進(jìn)程撼唾。 macOS Sierra廉邑，iOS 10，watchOS 3和tvOS 10都采用了新的基礎(chǔ)架構(gòu)來(lái)記錄這些錯(cuò)誤倒谷，這些操作系統(tǒng)生成的崩潰報(bào)告列出了“終止原因”字段中的錯(cuò)誤消息蛛蒙。

Triggered by Thread ／crash Thread發(fā)生異常的線程

以下部分解釋了一些最常見(jiàn)的異常類型。

Bad Memory Access [EXC_BAD_ACCESS // SIGSEGV // SIGBUS]

該進(jìn)程嘗試訪問(wèn)無(wú)效的內(nèi)存渤愁，或試圖以內(nèi)存保護(hù)級(jí)別不允許的方式訪問(wèn)內(nèi)存（例如宇驾，寫(xiě)入只讀內(nèi)存）。 異常子類型字段包含描述錯(cuò)誤的kern_return_t和不正確訪問(wèn)的內(nèi)存的地址猴伶。

這里有一些關(guān)于調(diào)試壞內(nèi)存訪問(wèn)崩潰的提示：

1 如果objc_msgSend或objc_release靠近崩潰線程的Backtraces頂部，則進(jìn)程可能試圖向釋放的對(duì)象發(fā)送消息。 你應(yīng)該使用Zombies instrument來(lái)分析應(yīng)用程序他挎，以便更好地理解這次崩潰的情況筝尾。

2 如果gpus_ReturnNotPermittedKillClient接近崩潰線程的Backtraces頂部，則該進(jìn)程被終止办桨，因?yàn)樗噲D在后臺(tái)使用OpenGL ES或Metal進(jìn)行渲染筹淫。 請(qǐng)參閱QA1766：QA1766: How to fix OpenGL ES application crashes when moving to the background

3 在啟用Address Sanitizer的情況下運(yùn)行您的應(yīng)用程序。 地址清理程序在編譯代碼中的內(nèi)存訪問(wèn)中添加額外的工具呢撞。 當(dāng)你的應(yīng)用程序運(yùn)行時(shí)损姜，如果內(nèi)存以可能導(dǎo)致崩潰的方式被訪問(wèn)，Xcode會(huì)提醒你殊霞。 （不理解）

[EXC_CRASH // SIGABRT]

該過(guò)程異常退出摧阅。 這種異常類型崩潰的最常見(jiàn)原因是未被捕獲的Objective-C / C ++異常和對(duì)abort（）的調(diào)用。

如果App Extensions需要花費(fèi)太多時(shí)間來(lái)初始化（看門(mén)狗終止a watchdog termination）绷蹲，那么App Extensions將終止于此異常類型棒卷。 如果擴(kuò)展在啟動(dòng)時(shí)因掛起而死亡，則生成的崩潰報(bào)告的Exception Subtype將為L(zhǎng)AUNCH_HANG祝钢。 由于擴(kuò)展沒(méi)有主函數(shù)比规，任何花在初始化上的時(shí)間都出現(xiàn)在擴(kuò)展庫(kù)和相關(guān)庫(kù)中的靜態(tài)構(gòu)造函數(shù)和+load方法中。 你應(yīng)該盡可能地推遲這項(xiàng)工作拦英。

Trace Trap [EXC_BREAKPOINT // SIGTRAP]跟蹤陷阱

與異常退出相似蜒什，此異常旨在讓附加的調(diào)試器在執(zhí)行過(guò)程的特定時(shí)刻中斷進(jìn)程。 你可以使用__builtin_trap（）函數(shù)從你自己的代碼中觸發(fā)這個(gè)異常疤估。 如果沒(méi)有附加調(diào)試器灾常，則會(huì)終止該過(guò)程并生成崩潰報(bào)告。

較低級(jí)別的庫(kù)（例如libdispatch）會(huì)在遇到致命錯(cuò)誤時(shí)捕獲進(jìn)程做裙。 有關(guān)該錯(cuò)誤的其他信息可以在崩潰報(bào)告的“附加診斷信息”部分或設(shè)備的控制臺(tái)中找到

具體的查看Backtraces (崩潰詳細(xì))以確定遇到意外情況的位置岗憋。 其他信息也可能已記錄到設(shè)備的控制臺(tái)。 您應(yīng)該修改崩潰位置的代碼以正常處理運(yùn)行時(shí)故障锚贱。 例如仔戈，使用可選綁定而不是強(qiáng)制解包可選。

非法指令[EXC_BAD_INSTRUCTION // SIGILL]

該進(jìn)程試圖執(zhí)行非法或未定義的指令拧廊。 該進(jìn)程可能試圖通過(guò)錯(cuò)誤配置的函數(shù)指針跳轉(zhuǎn)到無(wú)效地址监徘。

在Intel處理器上，ud2操作碼會(huì)導(dǎo)致EXC_BAD_INSTRUCTION異常吧碾，但通常用于捕獲進(jìn)程以進(jìn)行調(diào)試凰盔。 如果在運(yùn)行時(shí)遇到意外情況，英特爾處理器上的Swift代碼將以此異常類型終止倦春。 詳情請(qǐng)參閱跟蹤陷阱户敬。

退出[SIGQUIT]

該進(jìn)程在另一個(gè)具有管理其生命周期的進(jìn)程的請(qǐng)求下被終止落剪。 SIGQUIT并不意味著這個(gè)過(guò)程崩潰了，但它可能會(huì)以可檢測(cè)的方式行事尿庐。

在iOS上忠怖，如果主機(jī)應(yīng)用程序的加載時(shí)間過(guò)長(zhǎng)，它將被退出抄瑟。 崩潰報(bào)告中顯示的Backtraces不可能指向負(fù)責(zé)任的代碼凡泣。 最有可能的是，擴(kuò)展啟動(dòng)路徑上的其他一些代碼需要很長(zhǎng)時(shí)間才能完成皮假，但是在時(shí)間限制之前完成鞋拟，因此當(dāng)擴(kuò)展退出時(shí)，執(zhí)行已經(jīng)移到了Backtraces中顯示的代碼惹资。 您應(yīng)該對(duì)擴(kuò)展進(jìn)行概要分析贺纲，以便更好地理解啟動(dòng)過(guò)程中的大部分工作，并將該工作轉(zhuǎn)移到后臺(tái)線程或?qū)⑵溲舆t至稍后（在加載擴(kuò)展后）

Killed [SIGKILL]

該過(guò)程在系統(tǒng)的請(qǐng)求下被終止布轿。查看終止原因字段以更好地了解終止的原因哮笆。

終止原因字段將包含一個(gè)名稱空間，后跟一個(gè)代碼汰扭。以下代碼是特定于watchOS的稠肘。

終止代碼0xc51bad01表示由于在執(zhí)行后臺(tái)任務(wù)時(shí)使用了太多的CPU時(shí)間，所以手表應(yīng)用程序被終止萝毛。為了解決這個(gè)問(wèn)題项阴，優(yōu)化執(zhí)行后臺(tái)任務(wù)的代碼以獲得更高的CPU效率，或者減少應(yīng)用程序在后臺(tái)運(yùn)行時(shí)的工作量笆包。

終止代碼0xc51bad02表示由于在分配的時(shí)間內(nèi)未能完成后臺(tái)任務(wù)而終止了手表應(yīng)用程序环揽。要解決此問(wèn)題，請(qǐng)減少在后臺(tái)運(yùn)行時(shí)應(yīng)用程序執(zhí)行的工作量庵佣。

終止代碼0xc51bad03指示觀看應(yīng)用程序在分配的時(shí)間內(nèi)未能完成后臺(tái)任務(wù)歉胶，并且系統(tǒng)總體上足夠忙，以至于應(yīng)用程序可能沒(méi)有接收到執(zhí)行后臺(tái)任務(wù)的CPU時(shí)間巴粪。盡管應(yīng)用程序可以通過(guò)減少在后臺(tái)任務(wù)中執(zhí)行的工作量來(lái)避免此問(wèn)題通今，但是0xc51bad03并不表示應(yīng)用程序出錯(cuò)了。更可能的是肛根，由于整體系統(tǒng)負(fù)載辫塌，應(yīng)用程序無(wú)法完成其工作。

保護(hù)資源違規(guī)[EXC_GUARD]

這個(gè)過(guò)程違反了有保護(hù)的資源保護(hù)派哲。 系統(tǒng)庫(kù)可能會(huì)將某些文件描述符標(biāo)記為被保護(hù)臼氨，之后對(duì)這些描述符的正常操作將觸發(fā)EXC_GUARD異常（當(dāng)它想操作這些文件描述符時(shí)，系統(tǒng)使用特殊的“保護(hù)”私有API）芭届。 這可以幫助您快速追蹤問(wèn)題储矩，如關(guān)閉由系統(tǒng)庫(kù)打開(kāi)的文件描述符感耙。 例如，如果一個(gè)應(yīng)用程序關(guān)閉了用于訪問(wèn)支持Core Data存儲(chǔ)的SQLite文件的文件描述符椰苟，那么核心數(shù)據(jù)將在稍后神秘地崩潰抑月。 守護(hù)異常很快就會(huì)注意到這些問(wèn)題，從而使它們更易于調(diào)試舆蝴。

資源限制[EXC_RESOURCE]

該過(guò)程超出了資源消耗限制。這是來(lái)自操作系統(tǒng)的通知题诵，該進(jìn)程正在使用太多的資源洁仗。確切的資源列在“例外子類型”字段中。如果異常注釋字段包含非致命條件性锭，則即使生成崩潰報(bào)告赠潦，該過(guò)程也不會(huì)被終止。

MEMORY異常表示該進(jìn)程已超過(guò)系統(tǒng)強(qiáng)加的內(nèi)存限制草冈。這可能是終止過(guò)量?jī)?nèi)存使用的先兆她奥。

異常子類型WAKEUPS表示進(jìn)程中的線程每秒被喚醒的次數(shù)太多，這迫使CPU醒來(lái)的頻率很高怎棱，消耗電池壽命哩俭。

通常，這是由線程間通信（通常使用peformSelector：onThread：或dispatch_async）導(dǎo)致的拳恋，這些通信不知不覺(jué)地發(fā)生得比應(yīng)該更頻繁凡资。因?yàn)橛|發(fā)這種異常的通信發(fā)生的頻率非常頻繁，所以通常會(huì)有多個(gè)具有非常相似的Backtraces的后臺(tái)線程 - 指示通信起源的位置谬运。

其他異常類型

某些崩潰報(bào)告可能包含一個(gè)未命名的“例外類型”隙赁，將以十六進(jìn)制值打印（例如00000020）梆暖。 如果您收到這些崩潰報(bào)告之一伞访，請(qǐng)直接查看“例外代碼”字段以獲取更多信息。

異常代碼0xbaaaaaad表示日志是整個(gè)系統(tǒng)的堆椇洳担快照厚掷，而不是崩潰報(bào)告。 要拍攝堆疊照片滑废，請(qǐng)按主頁(yè)按鈕和任何音量按鈕蝗肪。 通常這些日志是由用戶偶然創(chuàng)建的，并不表示錯(cuò)誤蠕趁。

異常代碼0xbad22222表示一個(gè)VoIP應(yīng)用程序已被iOS終止薛闪，因?yàn)樗謴?fù)得太頻繁。

異常代碼0x8badf00d表示應(yīng)用程序已被iOS終止俺陋，因?yàn)榘l(fā)生了看門(mén)狗超時(shí)豁延。 應(yīng)用程序花了太長(zhǎng)時(shí)間才能啟動(dòng)昙篙，終止或響應(yīng)系統(tǒng)事件。 一個(gè)常見(jiàn)的原因是在主線程上進(jìn)行同步聯(lián)網(wǎng)诱咏。 無(wú)論什么操作苔可，線程0都需要移動(dòng)到后臺(tái)線程，或者以不同的方式進(jìn)行處理袋狞，這樣就不會(huì)阻塞主線程焚辅。

異常代碼0xc00010ff表示該應(yīng)用程序因響應(yīng)熱事件而被操作系統(tǒng)殺死。 這可能是由于發(fā)生此次崩潰的特定設(shè)備或其所在的環(huán)境所引起的問(wèn)題苟鸯。有關(guān)使您的應(yīng)用程序更有效地運(yùn)行的提示同蜻，請(qǐng)參閱iOS Performance and Power Optimization with Instruments。

異常代碼0xdead10cc表示應(yīng)用程序已被操作系統(tǒng)終止早处，因?yàn)樗趻炱鹌陂g持有文件鎖或sqlite數(shù)據(jù)庫(kù)鎖湾蔓。 如果您的應(yīng)用程序在掛起時(shí)對(duì)鎖定文件或sqlite數(shù)據(jù)庫(kù)執(zhí)行操作，則必須請(qǐng)求額外的后臺(tái)執(zhí)行時(shí)間才能完成這些操作砌梆，并在掛起之前放棄鎖定默责。

ps 通過(guò)從多任務(wù)托盤(pán)中(雙擊home)刪除應(yīng)用程序來(lái)終止暫停的應(yīng)用程序不會(huì)生成崩潰報(bào)告。 一旦應(yīng)用程序暫停咸包，它隨時(shí)可以由iOS終止桃序，因此不會(huì)生成崩潰報(bào)告。

其他診斷信息

Application Specific Information：在進(jìn)程終止之前捕獲的framework錯(cuò)誤消息

Kernel Messages：內(nèi)核信息 代碼簽名問(wèn)題的詳細(xì)信息

Dyld Error Messages：錯(cuò)誤消息由動(dòng)態(tài)鏈接器發(fā)出

當(dāng)一個(gè)流程因?yàn)殒溄拥目蚣芏唤K止時(shí)诉儒，生成的崩潰報(bào)告中“應(yīng)用程序特定信息”部分的摘錄無(wú)法找到葡缰。

比如Dyld Error Message:

Dyld Message: Library not loaded: @rpath/MyCustomFramework.framework/MyCustomFramework

Referenced from: /private/var/containers/Bundle/Application/CD9DB546-A449-41A4-A08B-87E57EE11354/TheElements.app/TheElements

Reason: no suitable image found.

當(dāng)進(jìn)程因無(wú)法快速加載其初始視圖控制器而終止時(shí)生成的崩潰報(bào)告中的“應(yīng)用程序特定信息”部分的摘錄。

比如Application Specific Information:

com.example.apple-samplecode.TheElements failed to scene-create after 19.81s (launch took 0.19s of total time limit 20.00s)

Elapsed total CPU time (seconds): 7.690 (user 7.690, system 0.000), 19% CPU

Elapsed application CPU time (seconds): 0.697, 2% CPU

Backtraces回溯

崩潰報(bào)告中最有用的部分是每個(gè)進(jìn)程線程在其終止時(shí)的回溯忱反。 這些跟蹤中的每一個(gè)與您在使用調(diào)試器暫停過(guò)程時(shí)所看到的類似

如

Thread 0 name: Dispatch queue: com.apple.main-thread

Thread 0 Crashed:

0? TheElements? ? ? ? ? ? ? ? ? 0x000000010006bc20 -[AtomicElementViewController myTransitionDidStop:finished:context:] (AtomicElementViewController.m:203)

1? UIKit? ? ? ? ? ? ? ? ? ? ? ? 0x0000000194cef0f0 -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 312

2? UIKit? ? ? ? ? ? ? ? ? ? ? ? 0x0000000194ceef30 -[UIViewAnimationState animationDidStop:finished:] + 160

3? QuartzCore? ? ? ? ? ? ? ? ? ? 0x0000000192178404 CA::Layer::run_animation_callbacks(void*) + 260

4? libdispatch.dylib? ? ? ? ? ? 0x000000018dd6d1c0 _dispatch_client_callout + 16

5? libdispatch.dylib? ? ? ? ? ? 0x000000018dd71d6c _dispatch_main_queue_callback_4CF + 1000

6? CoreFoundation? ? ? ? ? ? ? ? 0x000000018ee91f2c __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12

7? CoreFoundation? ? ? ? ? ? ? ? 0x000000018ee8fb18 __CFRunLoopRun + 1660

8? CoreFoundation? ? ? ? ? ? ? ? 0x000000018edbe048 CFRunLoopRunSpecific + 444

9? GraphicsServices? ? ? ? ? ? ? 0x000000019083f198 GSEventRunModal + 180

10? UIKit? ? ? ? ? ? ? ? ? ? ? ? 0x0000000194d21bd0 -[UIApplication _run] + 684

11? UIKit? ? ? ? ? ? ? ? ? ? ? ? 0x0000000194d1c908 UIApplicationMain + 208

12? TheElements? ? ? ? ? ? ? ? ? 0x00000001000653c0 main (main.m:55)

13? libdyld.dylib? ? ? ? ? ? ? ? 0x000000018dda05b8 start + 4

第一行列出當(dāng)前正在執(zhí)行的調(diào)度隊(duì)列的線程號(hào)和標(biāo)識(shí)符 剩下的就是堆棧信息了 從左到右依次為

堆棧幀號(hào)泛释。 堆棧框架以調(diào)用順序呈現(xiàn)温算，其中框架0是在執(zhí)行暫停時(shí)執(zhí)行的功能怜校。 第一幀是調(diào)用第零幀的函數(shù)，依此類推注竿。

堆棧幀的執(zhí)行函數(shù)所在的二進(jìn)制文件的名稱茄茁。

對(duì)于第零幀，執(zhí)行暫停時(shí)正在執(zhí)行的機(jī)器指令的地址巩割。 對(duì)于剩余的堆棧幀裙顽，當(dāng)控制權(quán)返回到堆棧幀時(shí)，將執(zhí)行的機(jī)器指令的地址宣谈。

在符號(hào)化的崩潰報(bào)告中愈犹，堆棧框架中的函數(shù)的方法名稱。