iOS崩溃信息总结

iOS崩溃信息总结

崩溃类型

1. Bad Memory Access [EXC_BAD_ACCESS // SIGSEGV // SIGBUS]
   内存相关的崩溃，工具：Zombies
2. Abnormal Exit [EXC_CRASH // SIGABRT]
   异常退出，如果main方法没有被执行就退出，则崩溃的Subtype为 LAUNCH_HANG
3. Trace Trap [EXC_BREAKPOINT // SIGTRAP]
   与异常退出类似，如果存在debugger，则它被唤起；否则，则与异常退出的处理一致；
4. Guarded Resource Violation [EXC_GUARD]
   访问非法资源，例如：文件描述符已经被关闭，还继续访问
5. Resource Limit [EXC_RESOURCE]
   达到资源访问上限，这不是崩溃，而是os发出的一个通知

一些特殊异常码 参考资料

1. 0x8badf00d 读作“ate bad food”，这个异常一般是因为系统监视器（watch dog）发现超时现象，终止app抛出，比如启动或终止超时，或者是响应系统事件超时。

   系统事件列表：
   application:didFinishLaunchingWithOptions:
   applicationWillResignActive:
   applicationDidEnterBackground:
   applicationWillEnterForeground:
   applicationDidBecomeActive:
   applicationWillTerminate:

2. 0xbad22222 标志VoIP类应用因为频繁启动终止。

3. 0xdead10cc 读作“dead lock”，当应用在后台运行时，由于占用（hold onto）系统资源（比如通讯录数据库），被操作系统终止。

4. 0xdeadfa11 读作“dead fall”，标志应用程序可能因为无响应被用户强行终止。

5. 0xbaaaaaad 当前log是整个系统的快照，而不是崩溃报告；触发机制：home键+音量键，通常是用户不小心创建的

6. 0xc00010ff：系统响应热（thermal）事件，导致app被杀掉；通常与特定的手机或环境有关。

崩溃信息参考

1. Incident Identifier: 崩溃报告的id编号；
2. CrashReporter Key：与device id一一对应，可以理解为device id的MD5值；
3. Binary images：崩溃时已经加载的二进制文件；

符号化iOS Crash文件的3种方法参考资料

1. 使用XCode

   需要3个文件，把它们放在一个目录，然后把.crash文件拖到Device Logs，选中该log，点击菜单“符号化”即可；

   1. crash报告（.crash文件）
   2. 符号文件 (.dSym文件)
   3. 应用程序文件 (appName.app文件，把IPA文件后缀改为zip，然后解压，Payload目录下的appName.app文件), 这里的appName是你的应用程序的名称。

2. 使用命令行工具symbolicatecrash

   1. 依然将“.app“, “.dSYM”和 ".crash"文件放到同一个目录下
   2. 输入命令:

   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 
   

3. 使用命令行工具atos

   语法：atos [-o AppName.app/AppName] -l loadAddress [-arch architecture] queryAddress...

   1. -o和-l参数必不可少，-arch参数可以忽略，查询地址可以多个，例如：Last Exception Backtrace中所有的地址
   2. -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

其他相关信息

1. UUID: 每一个可执行程序都有一个build UUID来唯一标识
   • crash文件中查询：
     1. crash文件中的位置：
        Binary Images:
        0x1000dc000 - 0x100237fff OneAPMDemoTest arm64 <0328eee551ce3e2da04c1cd61cec89c4> /var/mobile/Containers/Bundle/Application/B1554786-0F88-4409-9D1A-2011E7B2679D/OneAPMDemoTest.app/OneAPMDemoTest
     2. 查询“Binary Images:”,显示2行

           $ 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