前言
作为一个程序员,和八阿哥(BUG) 打交道是家常便饭,而苹果也帮我们生成了很多 crash 日志来帮助我们分析错误的产生.
下面主要说说如何用辅助工具symbolicatecrash
通过分析dSYM
等文件产生有用的 log 日志
获取工具/文件
先去应用程序–> Xocde–>右键显示报内容,然后根据下面图片显示,一步一步找到symbolicatecrash
文件,接下来,咱们把它备份到桌面的新建文件夹里去.
日志文件
将真机连接 Xcode, 然后按照如下的方式获取 carsh 日志文件
dSYM
debugging SYMbols,又称为调试符号表,是苹果为了方便调试和定位问题而使用的一种调试方案,本质上使用的是起源于贝尔实验室的DWARF(Debugging With Attributed Record Formats).
对我们分析 crash 起到作用的其实是子目录Contents--Resources--DWARF
下的与 App 同名的文件,咱们也把这个单独拷贝出来备用
app
这个就不用多说了, ipa
存档每次发布的xcarchive
咱们分析crash, 同时具备了crash日志文件
, dSYM
,app
这3个东西才能开始分析.而 dSYM
和 app
都在我们的xcarchive
文件里解包可以得到,这就是为什么我们一定要在每次发布版本的时候,将 xcode 自动生成的xcarchive
文件保存/归档.
解析过程
等如下文件齐全了,咱们就可以开始解析了
1.cd 到下面几个文件的目录下
2.输入命令行, XXX.log 或者 XXX.crash,表示将结果输出到 a.log 文件,注意空格
./symbolicatecrash /ABC/iWeidao.crash /ABC/iWeidao.app.dSYM > a.log
3.打开 a.log, 查看Last exception
,忽略系统自己的模块/库,将我们自己模块儿的地址纪录下来,此处是 0x100050000),后面多处会用到,
4.利用atos
方法,输入模块地址,进入调试模式,注意armv7 , arm64
,根据环境选择一个即可):
$atos -o iWeidao -arch armv7 -l 0x100050000,然后回车
5.此步无报错可忽略,直接进入6
假如报错 DEVELOPER_XXX
什么的,输入如下命令,注意 Xcode.app
是与你应用程序里 Xcode 的名称一致的.命令行如下:
$export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer
6.将a.log
里每一处自己项目模块崩溃的地址依次输入进去,比如上图里的0x100581ea8
0x100569e6c
,每输入一次并回车,命令行都会返回当前崩溃所在行 ,比如
即可看到具体崩溃所在文件,所在行
比较 UUID
有个童鞋问我,如何知道产生crash 日志和咱们分析的dSYM 包是不是同一个,那么,过程如下:
1.查看 crash 日志那个包的 UUID
2.查看咱们包的 UUID
$dwarfdump –uuid app.dSYM
结果如下:
这时候一个是大写,一个是小写,转化后如果是一致的,则表示是同一个包啦~
谢谢
这只能帮助我们定位,缩小范围,具体的情况还得靠程序猿们自己努力~fighting~
原创文章,转载请注明地址: https://kevinmky.github.io