iOS崩潰信息總結(jié)
崩潰類型
- Bad Memory Access [EXC_BAD_ACCESS // SIGSEGV // SIGBUS]
內(nèi)存相關(guān)的崩潰，工具：Zombies - Abnormal Exit [EXC_CRASH // SIGABRT]
異常退出，如果main方法沒(méi)有被執(zhí)行就退出，則崩潰的Subtype為 LAUNCH_HANG - Trace Trap [EXC_BREAKPOINT // SIGTRAP]
與異常退出類似，如果存在debugger，則它被喚起；否則，則與異常退出的處理一致； - Guarded Resource Violation [EXC_GUARD]
訪問(wèn)非法資源，例如：文件描述符已經(jīng)被關(guān)閉，還繼續(xù)訪問(wèn) - Resource Limit [EXC_RESOURCE]
達(dá)到資源訪問(wèn)上限，這不是崩潰，而是os發(fā)出的一個(gè)通知
一些特殊異常碼 參考資料
-
0x8badf00d 讀作“ate bad food”，這個(gè)異常一般是因?yàn)橄到y(tǒng)監(jiān)視器（watch dog）發(fā)現(xiàn)超時(shí)現(xiàn)象，終止app拋出，比如啟動(dòng)或終止超時(shí)，或者是響應(yīng)系統(tǒng)事件超時(shí)。
系統(tǒng)事件列表：
application:didFinishLaunchingWithOptions:
applicationWillResignActive:
applicationDidEnterBackground:
applicationWillEnterForeground:
applicationDidBecomeActive:
applicationWillTerminate: 0xbad22222 標(biāo)志VoIP類應(yīng)用因?yàn)轭l繁啟動(dòng)終止。
0xdead10cc 讀作“dead lock”，當(dāng)應(yīng)用在后臺(tái)運(yùn)行時(shí)，由于占用（hold onto）系統(tǒng)資源（比如通訊錄數(shù)據(jù)庫(kù)），被操作系統(tǒng)終止。
0xdeadfa11 讀作“dead fall”，標(biāo)志應(yīng)用程序可能因?yàn)闊o(wú)響應(yīng)被用戶強(qiáng)行終止。
0xbaaaaaad 當(dāng)前l(fā)og是整個(gè)系統(tǒng)的快照，而不是崩潰報(bào)告；觸發(fā)機(jī)制：home鍵+音量鍵，通常是用戶不小心創(chuàng)建的
0xc00010ff：系統(tǒng)響應(yīng)熱（thermal）事件，導(dǎo)致app被殺掉；通常與特定的手機(jī)或環(huán)境有關(guān)。
崩潰信息參考
- Incident Identifier: 崩潰報(bào)告的id編號(hào)；
- CrashReporter Key：與device id一一對(duì)應(yīng)，可以理解為device id的MD5值；
- Binary images：崩潰時(shí)已經(jīng)加載的二進(jìn)制文件；
符號(hào)化iOS Crash文件的3種方法參考資料
-
使用XCode
需要3個(gè)文件，把它們放在一個(gè)目錄，然后把.crash文件拖到Device Logs，選中該log，點(diǎn)擊菜單“符號(hào)化”即可；
- crash報(bào)告（.crash文件）
- 符號(hào)文件 (.dSym文件)
- 應(yīng)用程序文件 (appName.app文件，把IPA文件后綴改為zip，然后解壓，Payload目錄下的appName.app文件), 這里的appName是你的應(yīng)用程序的名稱。
-
使用命令行工具symbolicatecrash
- 依然將“.app“, “.dSYM”和 ".crash"文件放到同一個(gè)目錄下
- 輸入命令:
export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash appName.crash appName.app > appName.log -
使用命令行工具atos
語(yǔ)法：atos [-o AppName.app/AppName] -l loadAddress [-arch architecture] queryAddress...
- -o和-l參數(shù)必不可少，-arch參數(shù)可以忽略，查詢地址可以多個(gè)，例如：Last Exception Backtrace中所有的地址
- -o參數(shù)的二進(jìn)制包可以是ipa包中的，也可以從dSYM文件中獲取，參考以下示例
示例：2種方法均可，
xcrun atos -o OneAPMDemoTest.app.dSYM/Contents/Resources/DWARF/OneAPMDemoTest -l 0x1000dc000 -arch arm64 0x1001a5a58
xcrun atos -o OneAPMDemoTest.app/OneAPMDemoTest -l 0x1000dc000 0x1001a5a58
其他相關(guān)信息
- UUID: 每一個(gè)可執(zhí)行程序都有一個(gè)build UUID來(lái)唯一標(biāo)識(shí)
- crash文件中查詢：
- crash文件中的位置：
Binary Images:
0x1000dc000 - 0x100237fff OneAPMDemoTest arm64 <0328eee551ce3e2da04c1cd61cec89c4> /var/mobile/Containers/Bundle/Application/B1554786-0F88-4409-9D1A-2011E7B2679D/OneAPMDemoTest.app/OneAPMDemoTest - 查詢“Binary Images:”,顯示2行
- crash文件中的位置：
- crash文件中查詢：
$ grep --after-context=1 "Binary Images:" *crash //顯示前二行，命令更通用
3. 在crash文件中查詢“appName armv”,顯示1行；
$ grep "OneAPMDemoTest arm64" *crash //命令更具體，每次需要修改
4. 顯示：
0x1000dc000 - 0x100237fff OneAPMDemoTest arm64 <0328eee551ce3e2da04c1cd61cec89c4> /var/mobile/Containers/Bundle/Application/B1554786-0F88-4409-9D1A-2011E7B2679D/OneAPMDemoTest.app/OneAPMDemoTest
* 二進(jìn)制文件中查詢：
$xcrun dwarfdump --uuid OneAPMDemoTest.app/OneAPMDemoTest
UUID: 5D3C9DFD-9CAD-3C8A-889D-E95E532EC721 (armv7) OneAPMDemoTest.app/OneAPMDemoTest
UUID: 0328EEE5-51CE-3E2D-A04C-1CD61CEC89C4 (arm64) OneAPMDemoTest.app/OneAPMDemoTest
* dSYM文件中查詢：
使用mdls查看文件屬性
$ mdls OneAPMDemoTest.app.dSYM