使用 symbolicatecrash 符号化 crash log

symbolicatecrash

symbolicatecrash 是什么 ？ 

symbolicatecrash 是 Xcode 中自带的perl脚本工具，通过iPhone的崩溃日志和应用的.dSYM文件定位发生崩溃的位置，把Crashed日志中的一堆地址替换成代码相应位置。

什么时候能用到  symbolicatecrash ？

通常开发者开发软件时，真机是在身边的可以随时查看， 但如果是把APP安装到其他测试者手机 或者 是提交 App Store 审核被拒时就无法准确定位崩溃或报错原因了，这时候需要通过 xxx.crash 文件来分析解决问题，但问题是 xxx.crash 文件的内容是十六进制显示的 ，给我们的分析排错造成很大阻力， 所以这种情况下 我们需要用到 symbolicatecrash 来符号化。

如 ： 

审核被拒

分析被拒原因：

朋友你的应用运行在 iPhone OS 11.3.1 突然崩溃，下面是提供的报错日志，自己玩去吧 ！  有什么问题可以联系我们 ！！！

了解 crash log 

简单分析 crash log 文件结构 （一般可以分为6各部分 ） ：

1  报告头 （Header ）

2 异常代码(Exception Codes)

3 应用详情(Application Specific Information)

4. 回溯(Backtrace)

5. 线程状态(Thread State)

6. 二进制映像(Binary Images)

解读 ：

第一部分  Header

报告头 

这部分主要是应用相关信息 如： app_name (APP名称)   app_version（APP版本号）bundleID（APP 唯一标识）os_version （运行版本）

第二部分 异常代码 （Exception Codes）

Exception Codes

异常代码中包含有：异常类型(Exception Type)、异常子类型(Exception Subtype)、处理器的详细异常代码(processor-specific Exception Codes)和其它能提供更多Crash信息的字段，最后一个字段列出了触发Crash的线程索引。

异常类型(Exception Type) 有以下几种：

a   Bad Memory Access（坏内存访问） [EXC_BAD_ACCESS // SIGSEGV // SIGBUS]

这种类型的 Exception 是最为常见的 Crash ，通常是由于访问了无效的内存导致的。

SIGSEGV：访问了无效地址，没有物理内存对应该地址，通常由于重复释放对象导致。

SIGBUS：总线错误，与 SIGSEGV 不同的是，SIGBUS 访问的是有效地址，但总线访问异常，通常是访问了未对齐的数据。

SEGV：代表无效内存地址，比如空指针、未初始化指针、栈溢出等。

b.   Abnormal Exit （异常退出） [EXC_CRASH // SIGABRT]

SIGABRT：收到Abort信号退出，通常Foundation库中的容器为了保护状态正常会做一些检测，例如插入nil到数组或字典中等会遇到此类错误。（常见的是再网络请求时发生）。

c.   其它异常类型

有些异常类型没有被命名，以16进制数字表示。

0xbaaaaaad：意味着该Crash log并非一个真正的Crash，它仅仅只是包含了整个系统某一时刻的运行状态，由用户同时按Home键和音量键触发。

0xbad22222：当VoIP程序在后台太过频繁的激活时，系统可能会终止此类程序。

0x8badf00d：程序启动或者恢复时间过长被watch dog终止。

0xc00010ff：程序执行大量耗费CPU和GPU的运算，导致设备过热，触发系统过热保护被系统终止。

0xdead10cc：程序退到后台时还占用系统资源（如通讯录）被系统终止。

0xdeadfa11：程序无响应用户强制退出。当用户长按电源键，直到屏幕出现关机确认画面后再长按Home键，将强制退出应用。我们可以合理认为用户这么做的原因是应用程序没有响应。

第三部分 应用详情(Application Specific Information)有些Crash出现时，会产生额外的信息，这些信息能帮助用户更好地了解应用程序终止时的运行环境。示例如下。

3

第四部分  回溯(Backtrace)

这部分列出了发生Crash时线程的调用栈。示例如下。

4.png

5. 线程状态(Thread State) 

这部分列出了发生Crash的线程的状态，即寄存器和寄存器的值。示例如下。

5.png

6. 二进制映像(Binary Images)

这部分列出了当Crash发生时被装载进进程内存空间的依赖库或者模块。示例如下。

6.png

使用 symbolicatecrash  来分析崩溃日志

step 1  ：先在Mac 桌面创建一个新的文件夹，命名为crashAnalysis；

step 2  ：找到 symbolicatecrash 。拷贝 symbolicatecrash 到 crashAnalysis 文件夹中。

最新路径为 ： Xcode.app   -- >  Contents -- > SharedFrameworks  -- >DVTFoundation.framework  -- > Versions  -- > A  -- > Resources -- > symbolicatecrash

如图 ：

path.png

step 3  ：找到 .dSYM 文件拷贝到   crashAnalysis 文件夹中。

操作步骤 ：xcode --> Window --> Organizer ( command + shift +6 ) 

1.png

-- > 右键显示报内容 如图 ：

2.png

需要注意的是如果.dSYM 文件打开是没有任何内容的，是不可用的。这个时候必须重新生成给文件，在这之前需要在 xcode 中进行如下配置：Build Settings --> 搜索 dsym 选项改为DWARF with dSYM file 再次打包！

step 4  ：获取Crash日志的 .crash 文件 命名为  temp.crash

 1    如果是审核被拒 那么 崩溃日志需要下载下来改后缀名为.crash 如图 ：

下载截图.png

2 如果是真机的崩溃日志：

1.png

2.png

3.png

如此就拿到了所有需要的文件如图所示：

结果.png

step 5  ：打开终端 cd 进入 crashAnalysis ，执行以下命令就可以生成最终的 .crash 文件了 

export DEVELOPER_DIR=/Applications/XCode.app/Contents/Developer

./symbolicatecrash ./*.crash ./*.app.dSYM > analysis.crash          注 analysis.crash 需要自己命名 这里我使用的是 analysis 

接下来 symbolicatecrash 就会运行进行处理了。。。。。。。。。。。。

完成后你会开到 crashAnalysis 中多了个  analysis.crash 文件

5.png

step 6  ： 使用开发者工具 Xcode 打开 analysis.crash 文件 找到 Last Exception Backtrace: （  异常报错 ）处会看到变化  如图 ：

对比图.png

通过分析会看到崩溃原因是在向字典中插入一个 nil  对象造成的崩溃；

end.png

需要留意的是 这需要是同一版本的  .crash文件  .dSYM文件  才可以 ！

END