关于符号化(symbolic)和奔溃信息的分析

最初始的需求是:怎么定位线上的奔溃。

那就是捕获NSException,收集发送到后台统一处理。或者接入第三方奔溃统计的库,让他们把这些都做了。

这里面都有一个绕不过的问题是,得到的信息里有些是未符号化、显示为内存地址的信息:


关于符号化(symbolic)和奔溃信息的分析_第1张图片
是否符号化区别.png

怎么把地址转为对应的方法/函数就是符号化的任务。为啥叫符号化?在编译链接系统中,函数、变量这些都被认为是符号,有一个叫符号表的东西:

在符号表中,程序源代码中的每个标识符都和它的声明或使用信息绑定在一起,比如其数据类型、作用域以及内存地址。

所以解析过程需要的材料就是符号表,用它就可以用地址反向定位它的符号,得到需要的方法名。

  • 对于我们的APP,符号表就在dSYMs文件里,dSYMs应该就是debug symbols的缩写。
  • 对于系统库,如UIKit,在它们的framework里。/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/System/Library/Frameworks/UIKit.framework

奔溃信息的获取

  • 手机直接导入:window --> device --> view device logs. 这里面是格式化的crash文件,而且用Xcode查看时会自动符号化。
  • 在App Store上查看,这个需要用户在设置里同意了上传奔溃信息。
  • 前面两种几乎没什么暖用,对于线上的奔溃信息,得自己获取:
//没有捕获的异常会调用这里设置的函数
NSSetUncaughtExceptionHandler(analyzeAndSaveException);

void analyzeAndSaveException(NSException *exception){
    NSArray *symbols = [exception callStackSymbols];
    NSString *reason = [exception reason];
    NSDictionary *userInfo = [exception userInfo];
    NSString *name = [exception name];
    
    //按某种格式存到本地,然后上传到服务器
}

测试了下,在这个函数执行结束前,程序是不会狗带的,网络请求这种需要等待回调的肯定是不行了,但写到本地文件里还是可以的。

重点就是这个callStackSymbols,是引起奔溃的函数的调用栈,比如:

关于符号化(symbolic)和奔溃信息的分析_第2张图片
奔溃调用栈

这里就是部分符号化的,4-17这些都是显示的内存地址。如果是打包后安装的APP,调用栈跟上面直接连接xcode运行的又不同,关键性的第三点是这样的:
"3 CrashAnalyze 0x00000001000dbda8 CrashAnalyze + 32168"

符号化命令

atos -arch -o /Contents/Resources/DWARF/ -l

  • -arch 指定对应的cpu架构
  • -o 指定符号表路径,对APP本身的方法是dSYM文件路径/Contents/Resources/DWARF/app名称,对系统方法是/Users/shiwei/Library/Developer/Xcode/iOS\ DeviceSupport/10.3.3\ \(14G60\)/Symbols/System/Library/Frameworks/库名.framework/库名,注意路径有个版本区别。
  • -l 指定load address,就是这个库加载的地址
  • 最后的是需要被符号化的地址

从命令里可以看出,奔溃日志需要这些信息:

  • 机型,有了这个就知道cpu架构了
  • 系统版本,有系统版本可以知道对应的系统库的版本,但最好是每个库的UUID,ID总是不会错的。
  • 每个库的加载地址。

以前也有一些符号化和dSYMs文件的文章和工具,我试了下,好像没用了。区别是没有考虑load address的问题,具体的我没仔细考证。

怎么知道是哪个库的方法?

  • 调用栈里的每条前面都有库的名字,自己APP的代码就是APP的名称
  • 我观察到一点:加载地址是有区间的,比如加载地址从小到大是:libA --- libB --- libC,而需要符号化的地址落在libB和libC之间,那么就是libB的函数了。

怎么获取加载地址?

#import 
.....
uint32_t numImages = _dyld_image_count();
    for (uint32_t i = 0; i < numImages; i++) {
        const struct mach_header *header = _dyld_get_image_header(i);
        const char *name = _dyld_get_image_name(i);
        const char *p = strrchr(name, '/');
        if (p) {
             NSLog(@"module=%s, address=%p", p + 1, header);
        }
    }

怎么获取UUID?
iOS 如何获取 Mach-O 的 UUID

测试:

//对APP本身
atos -arch arm64 -o ~/Desktop/CrashAnalyze.app.dSYM/Contents/Resources/DWARF/CrashAnalyze -l 0x100068000 0x10006fd8c

-[ViewController triggerException] (in CrashAnalyze) (ViewController.m:61)

//对UIKit
atos -arch arm64 -o /Users/shiwei/Library/Developer/Xcode/iOS\ DeviceSupport/10.3.3\ \(14G60\)/Symbols/System/Library/Frameworks/UIKit.framework/UIKit -l 0x196f2d000 0x0000000196f71bd4

-[UIControl sendAction:to:forEvent:] (in UIKit) + 80

系统库的符号化更多看这里

最后

这些东西如果要自己手动处理确实很麻烦,因为必要的数据和材料都可以上传给服务器,所以做一套系统,自动上报crash信息,后台根据提供的符号表或dSYMs文件,再加上各个系统库的各个版本的符号表,就可以让程序自动去处理这些。

这样一个自动化的系统才更有价值吧!

然后看了下Bugly做了这样的处理,Bugly iOS 符号表配置

Understanding and Analyzing Application Crash Reports
iOS Crash分析必备:符号化系统库方法
符号表

你可能感兴趣的:(关于符号化(symbolic)和奔溃信息的分析)