开源地址：https://github.com/wuba/WBBlades
背景
在开发过程中，我们经常遇到一类问题，那就是如何将崩溃日志符号化。当遇到不可稳定复现的崩溃时，解析崩溃日志是我们查找问题最有效的手段。但是，原始的崩溃日志是未经符号化的地址，虽然在大多数情况下，我们可以直接或间接地借助符号表完成日志解析，但是在某些情况下，我们无法获取到APP的符号表，那么也就意味着常规的技术手段无法满足地址符号化的需求。那么如何在没有符号表的情况下将崩溃日志符号化？本文将从iOS应用二进制的角度给出无符号表条件下的符号化方案。
多种打包方式下的符号表
在正文开始之前，先来简单介绍下符号表。崩溃日志符号化所需要的符号表通常指dSYM文件，dSYM文件是用来记录调试信息的文件，其数据存储格式为DWARF格式。其数据来源为应用二进制文件的DEBUG段，记录的信息主要包括：文件路径信息、行号信息、变量与地址的映射、函数与地址的映射等。正是因为其存在地址与符号的映射关系，符号表才可以被用于解析崩溃日志。在得到崩溃日志和相应的符号表后，可借助symbolicatecrash工具实现日志符号化，具体过程在此不再赘述。如果没有symbolicatecrash工具，那么dwarfdump命令也可以逐条实现地址符号化。
1、 本地调试包
本地调试状态下，打包默认不生成dSYM文件，但是这并不意味着调试信息和符号信息丢失了。当我们本地连接Xcode打出来的包发生偶现崩溃时，可以通过Xcode提供的dsymutil工具将dSYM文件从应用程序的二进制文件中剥离。剥离出的dSYM文件即可借助相应symbolicatecrash实现地址符号化。
2、 APPStore包
在58同城APP 9.0版本发布后，有个别用户反馈APP存在连续启动崩溃的现象。但是从bugly 后台我们并没有发现相关的崩溃信息。最终在该用户的积极配合下，我们拿到了崩溃日志。但是由于服务器空间所限，58同城的dSYM文件在服务器保留2天后会自动清除，因此当我们想要依靠dSYM解析崩溃日志时却发现dSYM早已被删除，服务器上只保留了bugly生成的symbol文件。那么是否可以通过symbol文件来解析崩溃日志呢？答案当然是可以的，首先我们要了解什么是symbol文件。symbol文件实际上是bugly从dSYM文件中提取的函数地址符号映射关系。由于symbol文件只保留了函数地址符号映射，不包含文件路径、变量地址符号映射等信息，因此symbol相比于dSYM文件更轻量。symbol文件本质为文本文件，其格式为：起始指令地址 + 结束指令地址 + 代码所在函数名 + 代码所在文件及行号。以本次日志解析为例，我们拿到的崩溃偏移地址为B，通过文本扫描后发现函数F的L行代码的起始指令地址为A，结束指令地址C，地址满足A <= B <= C的原则，因此可以确定崩溃发生在F函数的L行。
3、 Jenkins包
58同城在业务开发阶段提供给测试同学的测试包都是通过Jenkins服务打包。随着业务的发展，58同城APP的体积越来越庞大，这就导致测试同学从Jenkins服务器上下载APP的时间较长。为了能够尽可能的减小下载体积，58同城将APP的符号表在打包期间从应用程序中剥离出来形成dSYM文件，保存在打包服务器中。因此测试同学下载的Jenkins包是不包含符号表信息的。由于剥离出来的dSYM文件较大，为了节省服务器空间，dSYM在保留2天后会自动清除。假设有这样一个场景，即测试同学下载了一个测试包，在测试到第三天时发生了不可稳定复现的崩溃，在这种即没有dSYM文件也没有symbol文件的情况下，如何才能恢复堆栈符号？
无符号表堆栈恢复方案简介
1、 思路
要想进行堆栈符号化，首先要了解崩溃日志的格式。
图片1.png
堆栈的符号化无非是找到地址与符号的映射关系，除了dSYM文件，是否还有其他文件中包含此种关系？
由于OC语言是门动态语言，在日常开发过程中，我们经常会利用这种动态特性去动态地获取类和方法。这就说明，在运行期间存在类名、方法名存在和地址的绑定关系，而这种绑定关系就存在于应用程序的二进制文件中。
2、 方案介绍
iOS应用的二进制文件为Mach-O文件，OC编写的应用程序中存在（__DATA,__objc_classlist）节，该节数据存储的是所有类的地址。（这里所说的地址是指距Mach-O文件起始地址的偏移地址）。arm64的二进制文件中，此地址指向一个class64的结构体。class64结构体起始8字节用于记录类的isa指针，指向类的元类。末尾8字节用于记录data，指向类的class64Info结构体。class64Info存储类名的字符串地址及方法列表地址。class64结构体和class64Info结构体如下
struct class64 {
unsigned long long isa;//元类在文件中的地址
unsigned long long superClass;
unsigned long long cache;
unsigned long long vtable;
unsigned long long data;//class64Info在文件中的地址
};
struct class64Info {
unsigned int flags;
unsigned int instanceStart;
unsigned int instanceSize;
unsigned int reserved;
unsigned long long instanceVarLayout;
unsigned long long name;//类名在文件中的地址
unsigned long long baseMethods;//方法列表在文件中的地址
unsigned long long baseProtocols;
unsigned long long instanceVariables;
unsigned long long weakInstanceVariables;
unsigned long long baseProperties;
};
方法列表中存储的是类的实例方法，如果想要查找类方法，那么需要先跳转到元类的class64Info结构体，再查找方法列表。根据上面的寻址后，我们能够找到每个类的所有类方法和实例方法。那么方法在方法列表中是如何存储的呢？首先来看一张简图
图片2.png
从上图可以看出，在方法列表中，前8字节为method64_list_t结构体，用于说明方法的数量，此后文件中连续存储method64_t结构体，通过method64_t我们可以找到这个方法的名称和函数起始地址。在这里，我们先简单总结下前面的内容：首先根据Mach-O文件的（__DATA,__objc_classlist）节获取所有类的地址，根据地址从Mach-O文件中读取class64结构体，根据class64结构体data成员记录的地址获取class64Info结构体。最后再根据class64Info结构体的baseMethods成员获取到实例方法列表（类方法需要读取元类数据，读取方法相同）。获取到方法列表的起始地址后，即可根据method64_list_t + N*method64_t的方式从文件中读取每个方法的函数地址。获取到的函数地址即为函数距离Mach-O文件的偏移地址，如函数地址为0xAAAA，则说明在Mach-O文件，从0xAAAA字节开始是某函数的地址，此后连续N字节为该函数的函数指令。
图片3.png
如何在Mach-O文件中获取函数地址
假设函数起始地址为0xAAAA，函数结束地址为0xBBBB，那么当崩溃堆栈显示偏移地址为0xAABB时，则说明崩溃指令位于该函数之类范围内，也就是说此函数发生崩溃。那么问题来了，根据上面所述的方法，可以通过Mach-O文件定位到函数的起始地址，可以通过崩溃日志确定崩溃发生时的指令偏移地址，那么如何才能确定函数的结束地址呢？在iOS系统中，一条arm64的指令为4字节，当函数结束时会执行一条ret指令，当我们从函数起始地址开始扫描，扫描到ret指令时即可认为函数结束。ret指令为无操作码指令，其指令固定为0xC0035FD6。我们从0xAAAA开始读取指令，每次按序获取4字节并读取这4字节的内容，如果内容为0xC0035FD6则认为函数结束。至此，可以简单地根据Mach-O文件将崩溃日志符号化。
3、 实践
58无符号表crash日志解析工具起源于一次需求开发，在需求开发过程中发现偶现的崩溃，崩溃极难复现。为此我们紧急研发了日志解析工具并命名为绣春刀。绣春刀自诞生之日起，多次在需求开发中发挥作用，辅助开发人员定位到启动时UIPasteboard引起的崩溃、NSDateFormatter引起的崩溃。目前绣春刀已经成为58质量保证不可缺少的工具。
总结、展望或规划
58绣春刀虽然为开发人员排查问题的提供了新的技术手段，但是由于其开发比较仓促，使用起来不是十分友好，需要相应的文档进行指导说明，需要了解崩溃日志的数据含义才能正确使用绣春刀。另外一方面，由于方案自身的限制，目前还不能解析除了OC方法以外的崩溃日志，如：block的崩溃、自定义C函数的崩溃。后续需要考虑如何将block的崩溃日志进行符号化。
参考文献
作者简介（必填）
邓竹立：58同城用户价值增长部-iOS技术部高级研发工程师。专注于客户端架构与性能优化，目前主要负责58同城iOS客户端微聊中间件的研发及APP工厂提效工具研发。
网友评论