34 Crash(一)定位

.dSYM(debugging SYMbols)又称为调试符号表，是苹果为了方便调试和定位问题而使用的一种调试方案，本质上使用的是起源于贝尔实验室的DWARF（Debugging With Attributed Record Formats）    友盟、Crashlytics 以及腾讯的bugly

了解CrashLog的还原原理和方法

分析崩溃日志的前提是我们需要有dSYM文件，这个文件是我们用archive打包时生成的.xcarchive后缀的文件包。一个良好的习惯是，在你打包提交审核的时候，将生成的.xcarchive与ipa文件一同拷贝一份，按照版本号保存下来，这样如果线上出现问题可以快速的找到你想要的文件来定位你的问题。

结合crash log 与 dSYM文件 来分析定位出代码崩溃

第一步:确定符号表和崩溃日志的一致性,

有了符号表文件，有了崩溃日志文件，在解析之前一定要确保二者的对应关系，否则就算按照下述步骤解析出内容也肯定是不准确的。二者的对应关系可以通过UUID来确定。

提取有用信息:

Xmen为应用的名称

NSConcreteMutableAttributedString addAttribute:value:range:: nil value 崩溃的原因是value为nil

" 4 Xmen 0x10073fb30 Xmen + 7600944" 它指出了应用名称，崩溃时的调用方法的地址(起点或者终点)，文件的地址以及方法所在的行的位置，我们需要的是这一个:"0x10073fb30"。

"dSYM UUID: 应用的udid,30833A40-0F40-3980-B76B-D6E86E4DBA85"。

"CPU Type: arm64"。

开始分析,使用dwarfdump命令

打开终端,进入到dsym:

cd /Dandy/XMEN/上线版本/2.0.17_105/aaaa.xcarchive/dSYMs

验证下崩溃日志中的UUID与本地的dYSM文件是否是相匹配的

dwarfdump --uuid Xmen.app.dSYM

发现与我们日志中的:UUID和CPU Type是相匹配的

第二步:  查找错误信息

dwarfdump --arch=arm64 --lookup 0x10073fb30  /Dandy/XMEN/上线版本/2.0.17_105/aaaa.xcarchive/dSYMs/Xmen.app.dSYM/Contents/Resources/DWARF/Xmen

"arm64"与"0x1008cf9c0"分别对应于上面我们从日志中提取出来的有用信息

"/Dandy/XMEN/上线版本/2.0.17_105/aaaa.xcarchive/dSYMs/Xmen.app.dSYM/Contents/Resources/DWARF/Xmen"对应于你本地dYSM文件目录

"Xmen"对应于你的app名称

第三步:

崩溃代码所在的文件的目录

崩溃代码所在的具体文件

崩溃代码所在的方法

崩溃代码具体在哪一行

----------------------------------------------------------------------------

符号表堆栈地址计算方式:

从上述堆栈中第9行可以看到，应用崩溃发生在运行时地址0x000f0846，该进程的运行时起始地址是0xa2000，崩溃处距离进程起始地址的偏移量为十进制的321606(对应十六进制为0x4E

0x000f0846 = 0xa2000 + 0x4E846

运行时堆栈地址 = 运行时起始地址 + 偏移量

堆栈中的起始地址和崩溃地址均为运行时地址，根据虚拟内存偏移量不变原理，只要提供了符号表TEXT段的起始地址，再加上偏移量（这里为0x4E846）就能得到符号表中的堆栈地址，即：

符号表堆栈地址 = 符号表起始地址 + 偏移量