iOS崩潰信息總結(jié)
崩潰類型
- Bad Memory Access [EXC_BAD_ACCESS // SIGSEGV // SIGBUS]
內(nèi)存相關(guān)的崩潰，工具：Zombies - Abnormal Exit [EXC_CRASH // SIGABRT]
異常退出，如果main方法沒有被執(zhí)行就退出，則崩潰的Subtype為 LAUNCH_HANG - Trace Trap [EXC_BREAKPOINT // SIGTRAP]
與異常退出類似，如果存在debugger，則它被喚起；否則，則與異常退出的處理一致； - Guarded Resource Violation [EXC_GUARD]
訪問非法資源，例如：文件描述符已經(jīng)被關(guān)閉，還繼續(xù)訪問 - Resource Limit [EXC_RESOURCE]
達到資源訪問上限，這不是崩潰，而是os發(fā)出的一個通知
一些特殊異常碼 參考資料
-
0x8badf00d 讀作“ate bad food”，這個異常一般是因為系統(tǒng)監(jiān)視器（watch dog）發(fā)現(xiàn)超時現(xiàn)象，終止app拋出，比如啟動或終止超時，或者是響應系統(tǒng)事件超時。
系統(tǒng)事件列表：
application:didFinishLaunchingWithOptions:
applicationWillResignActive:
applicationDidEnterBackground:
applicationWillEnterForeground:
applicationDidBecomeActive:
applicationWillTerminate: 0xbad22222 標志VoIP類應用因為頻繁啟動終止。
0xdead10cc 讀作“dead lock”，當應用在后臺運行時，由于占用（hold onto）系統(tǒng)資源（比如通訊錄數(shù)據(jù)庫），被操作系統(tǒng)終止。
0xdeadfa11 讀作“dead fall”，標志應用程序可能因為無響應被用戶強行終止。
0xbaaaaaad 當前l(fā)og是整個系統(tǒng)的快照，而不是崩潰報告；觸發(fā)機制：home鍵+音量鍵，通常是用戶不小心創(chuàng)建的
0xc00010ff：系統(tǒng)響應熱（thermal）事件，導致app被殺掉；通常與特定的手機或環(huán)境有關(guān)。
崩潰信息參考
- Incident Identifier: 崩潰報告的id編號；
- CrashReporter Key：與device id一一對應，可以理解為device id的MD5值；
- Binary images：崩潰時已經(jīng)加載的二進制文件；
符號化iOS Crash文件的3種方法參考資料
-
使用XCode
需要3個文件，把它們放在一個目錄，然后把.crash文件拖到Device Logs，選中該log，點擊菜單“符號化”即可；
- crash報告（.crash文件）
- 符號文件 (.dSym文件)
- 應用程序文件 (appName.app文件，把IPA文件后綴改為zip，然后解壓，Payload目錄下的appName.app文件), 這里的appName是你的應用程序的名稱。
-
使用命令行工具symbolicatecrash
- 依然將“.app“, “.dSYM”和 ".crash"文件放到同一個目錄下
- 輸入命令:
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
語法：atos [-o AppName.app/AppName] -l loadAddress [-arch architecture] queryAddress...
- -o和-l參數(shù)必不可少，-arch參數(shù)可以忽略，查詢地址可以多個，例如：Last Exception Backtrace中所有的地址
- -o參數(shù)的二進制包可以是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: 每一個可執(zhí)行程序都有一個build UUID來唯一標識
- 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
* 二進制文件中查詢：
$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