iOS崩溃堆栈信息的符号化解析

iOS崩溃堆栈信息的符号化解析,第1张

概述转载注明出处:点击打开链接最近一段时间,在iOS开发调试过程中以及上线之后,程序经常会出现崩溃的问题。简单的崩溃还好说,复杂的崩溃就需要我们通过解析Crash文件来分析了,解析Crash文件在iOS开发中是比较常见的。但在跟开发者沟通过程中,云捕小编发觉大家对iOS的应用符号表还不是很清楚。现在网上有很多关于解析崩溃堆栈信息的符号化的博客,但是大多质量参差不齐,或者有些细节没有注...

转载注明出处:点击打开链接

 

最近一段时间,在iOS开发调试过程中以及上线之后,程序经常会出现崩溃的问题。简单的崩溃还好说,复杂的崩溃就需要我们通过解析Crash文件来分析了,解析Crash文件在iOS开发中是比较常见的。但在跟开发者沟通过程中,云捕小编发觉大家对iOS的应用符号表还不是很清楚。

现在网上有很多关于解析崩溃堆栈信息的符号化的博客,但是大多质量参差不齐,或者有些细节没有注意到。今天总结一下对iOS崩溃符号化的使用和技巧:

@H_301_12@一.场景

当我们收集iOS的崩溃信息时,获取到的崩溃堆栈一般是如下的形式,全是十六进制的内存地址形式:

这样的格式我们很难看出实际含义,无法定位问题代码,只有将它们转化为可读的形式才有意义:

如上所示,我们一眼就能看明白,这次崩溃发生在VIEwController.m文件的68行,对应的方法是rangeException。那么这样的符号化又是如何实现的呢?

我们知道,开发者在使用Xcode开发调试App时,一旦遇到崩溃问题,开发者可以直接使用Xcode的调试器定位分析崩溃堆栈。但如果App发布上线,用户的手机发生了崩溃,我们就只能通过分析系统记录的崩溃日志来定位问题,在这份崩溃日志文件中,会指出App出错的函数内存地址,关键的问题,崩溃日志中只有地址,类似 0x2312e92f这种,这看起来岂不是相当头疼,那怎么办呢?

幸好有dSYM文件的存在,它是帮助苦逼的码农有效定位BUG问题的重要途径。崩溃堆栈里的函数地址可以借助dSYM文件来找到具体的文件名、函数名和行号信息的。实际上,在使用Xcode的Organizer查看崩溃日志时,就是根据本地存储的.dSYM文件进行了符号化的 *** 作。

@H_301_12@二.Xcode符号化工具

Xcode本身也提供了几个工具来帮助开发者执行函数地址符号化的 *** 作

@H_301_12@1、symbolicatecrash

symbolicatecrash是一个将堆栈地址符号化的脚本,输入参数是苹果官方格式的崩溃日志及本地的.dSYM文件,

执行方式如下:

Symbolicatecrash + 崩溃日志 + APP对应的.dSYM文件 + > + 输出到的文件,

但使用symbolicatecrash工具有很大的限制

(1)只能分析官方格式的崩溃日志,需要从具体的设备中导出,获取和 *** 作都不是很方便

(2)符号化的结果也是没有具体的行号信息的,也经常会出现符号化失败的情况。

实际上,Xcode的Organizer内置了symbolicatecrash工具,所以开发者才可以直接看到符号化的崩溃堆栈日志。

@H_301_12@2、atos

更普遍的情况是,开发者能获取到错误堆栈信息,而使用atos工具就是把地址对应的具体符号信息找到。它是一个可以把地址转换为函数名(包括行号)的工具,

执行方式如下:

atos -o executable -arch architecture -l loadAddress address

说明:

loadAddress 表示函数的动态加载地址,对应崩溃地址堆栈中 + 号前面的地址,即0x00048000

address 表示运行时地址、对应崩溃地址堆栈中第一个地址,即0x0004fbed  ,实际上,崩溃地址堆栈中+号前后的地址相加即是运行时地址,即0x00048000+ 31720= 0x0004fbed

执行命令查询地址的符号,可以看到如下结果:

-[VIEwController rangeException:] (in xx)(VIEwController.m:68)

@H_301_12@三.堆栈符号化原理

那么,如果我们自己来符号化堆栈,又该怎么实现呢?这里需要处理两种符号,包括用户符号和系统符号。

@H_301_12@1、用户堆栈的符号化

符号化的依据来自dSYM文件, dSYM文件也是Mach-o格式,我们按照Mach-o格式一步一步解析即可。

从图上我们可以大概的看出Mach-O可以分为3个部分

(1)header

(2)Segment

(3)section

如图所示,header后面是segment,然后再跟着section,而一个segment是可以包含多个section的。

我们把dSYM文件放入可视化工具:

该dSYM文件包含armv7和arm64两种架构的符号表,我们只看armv7(arm64同理),它偏移64,直接定位到64(0x00000040),这里就是上面的Mach header信息

跟我们符号表有关的两个地方,一是”LC_SYMTAB”,二是“LC_SEGMENT(__DWARF)” -> “Section header(__deBUG_line)”。

@H_301_12@LC_SYMTAB信息

定位地址: 偏移4096 + 64(0x1040),得到函数符号信息模块”Symbols”,把函数符号解析出来,比如第一个函数: “-[DKDlicenseAgreeementModel isAuthorize]”对应的内存地址:模块地址+43856

@H_301_12@“__deBUG_line”模块

这个模块里包含有代码文件行号信息,根据DWarf格式去一个一个解析

首先定位到SEGMENT:LC_SEGMENT(__DWARF),再定位到Section:__deBUG_line

它的偏移值:4248608,  4248608+ 64 = 0x40D460,定位到“Section(__DWARF,__deBUG_line)”

这里面就是具体的行号信息,根据DWarf格式去解析

解析出来的结果如下:

第一列是起始内存地址,第二列是结束内存地址,第三列是对应的函数名、文件名、行号信息,这样我们捕获到任意的崩溃信息后,都可以很轻松的还原了。

上面解析出来的Object-C符号倒没什么问题,但如果是C++或者Swift的符号就还需要特殊处理

@H_301_12@Swift符号:

Swift函数会进行命名重整(name mangling),所以从dSYM中解析出来的原始符号是不太直观的

我们使用”swift-demangle”来还原:swift-demangle –simplifIEd originname,结果如下:

@H_301_12@C++符号:

C++函数也会进行命名重整(name mangling),所以从dSYM中解析出来的原始符号如下:

我们使用”c++filt ”来还原: c++filt originname,结果如下:

@H_301_12@2、系统堆栈的符号化

未解析形式:

解析后:

Apple没有提供系统库符号表的下载功能,我们可以通过真机来获取

当把开发机连到MAC时,会首先把该机型的符号拷贝到电脑上。

“Processing symbol files”做的事情就是把系统符号拷贝到电脑,拷贝地址:

~/library/Developer/Xcode/iOS DeviceSupport

但这样有个缺陷,那就是你真机的iOS版本不会足够多,包含所有版本,所以系统符号会有缺失,另一个办法就是下载各种iOS固件,从固件中去解析。

@H_301_12@四.结语

在实际的项目开发中,崩溃问题的分析定位都不是采用这种方式,因为它依赖于系统记录的崩溃日志或错误堆栈,在本地开发调试阶段,是没有问题的。

如果在发布的线上版本出现崩溃问题,开发者是无法即时准确的取得错误堆栈。一般地,开发者都是接入第三方的崩溃监控服务(如网易云捕),实现线上版本崩溃问题的记录和跟踪。



作者:网易加固
链接:https://www.jianshu.com/p/953f0961157a
來源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

总结

以上是内存溢出为你收集整理的iOS崩溃堆栈信息的符号化解析全部内容,希望文章能够帮你解决iOS崩溃堆栈信息的符号化解析所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/web/998867.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-05-21
下一篇 2022-05-21

发表评论

登录后才能评论

评论列表(0条)

保存