iOS崩溃信息总结
崩溃类型
- Bad Memory Access [EXC_BAD_ACCESS // SIGSEGV // SIGBUS]
内存相关的崩溃，工具：Zombies - Abnormal Exit [EXC_CRASH // SIGABRT]
异常退出，如果main方法没有被执行就退出，则崩溃的Subtype为 LAUNCH_HANG - Trace Trap [EXC_BREAKPOINT // SIGTRAP]
与异常退出类似，如果存在debugger，则它被唤起；否则，则与异常退出的处理一致； - Guarded Resource Violation [EXC_GUARD]
访问非法资源，例如：文件描述符已经被关闭，还继续访问 - Resource Limit [EXC_RESOURCE]
达到资源访问上限，这不是崩溃，而是os发出的一个通知
一些特殊异常码 参考资料
-
0x8badf00d 读作“ate bad food”，这个异常一般是因为系统监视器（watch dog）发现超时现象，终止app抛出，比如启动或终止超时，或者是响应系统事件超时。
系统事件列表：
application:didFinishLaunchingWithOptions:
applicationWillResignActive:
applicationDidEnterBackground:
applicationWillEnterForeground:
applicationDidBecomeActive:
applicationWillTerminate: 0xbad22222 标志VoIP类应用因为频繁启动终止。
0xdead10cc 读作“dead lock”，当应用在后台运行时，由于占用（hold onto）系统资源（比如通讯录数据库），被操作系统终止。
0xdeadfa11 读作“dead fall”，标志应用程序可能因为无响应被用户强行终止。
0xbaaaaaad 当前log是整个系统的快照，而不是崩溃报告；触发机制：home键+音量键，通常是用户不小心创建的
0xc00010ff：系统响应热（thermal）事件，导致app被杀掉；通常与特定的手机或环境有关。
崩溃信息参考
- Incident Identifier: 崩溃报告的id编号；
- CrashReporter Key：与device id一一对应，可以理解为device id的MD5值；
- Binary images：崩溃时已经加载的二进制文件；
符号化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参数必不可少，-arch参数可以忽略，查询地址可以多个，例如：Last Exception Backtrace中所有的地址
- -o参数的二进制包可以是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
其他相关信息
- UUID: 每一个可执行程序都有一个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