符号化二进制崩溃问题

符号化二进制崩溃问题
1、首先拿到项目中的dSYM符号化文件,新建一个文件夹吧dSYM放里面,并且双击打开这个文件,然后执行下面命令:
dwarfdump --uuid dSYM文件查看uuid
例子如下:
符号化二进制崩溃问题
文章图片
图解 2、然后和crash文件中的UUID对比是相同,不一样的话说明不是一个包里面的。
3、拿到包的UUID如下命令,注意如果你拿到的是ipa的话先直接用直接使用归档工具归档,当然也可以使用先压缩后解压查看包的形式:
dwarfdump --uuid YourApp.app/YourApp
例子如下:
符号化二进制崩溃问题
文章图片
图解 4、如果四个的UUID一样说明没问题,这个项目包的crash,UUID是软件的一个唯一标识,不一样说明不是一个包,不要在解析了。当然你也要看仔细是64的还是arm7上的标识。
5、关于Jenkins打包,它会把以前的build文件覆盖掉,结果以前的dSYM文件和ipa包没法获取(亲自测试)。
7、Xcode工具symbolicatecrash解析iOS Crash文件,在找symbolicatecrash的时候需要注意,先执行下面命令在所有的安装包里面找到这个文件,主要用于项目在真机内部的crash,命令如下:
find /Applications/Xcode.app -name symbolicatecrash -type f
找到之后cd到这个文件夹下,copy出来就可以。
8、在桌面新建一个文件夹crash(自己随意就可以),然后把dSYM文件,symbolicatecrash工具,crash文件文件拷贝到这个文件夹下面,symbolicatecrash一般分析有crash类的文件,有时候苹果审核拒绝是因为一个crash的bug时候会顺便把crash附带上,这时候你就可以用这种方式分析,执行下面命令:
./symbolicatecrash ./*.crash ./*.app.dSYM > symbol.crash
其中symbol.crash文件就是解析后的crash文件,在这行这个命令的时候可能会出现下面错误:
Error: "DEVELOPER_DIR" is not defined at ./symbolicatecrash line 69.
解决办法:一定在上面一个命令之前执行就可以了
export DEVELOPER_DIR=/Applications/XCode.app/Contents/Developer
【符号化二进制崩溃问题】9、经验:在符号化之前先把dYSM中间中的UUIDcrash文件的UUID进行对比,如果不一样的话,说明不是这个版本造成的crash直接继续再找吧。
备注:以上7~9是真机crash日志的分析,三方堆栈分析见下面
10、关于其他三方上传的堆栈地址的时候,用atos分析,命令如下:
atos -o 项目名称.app.dSYM/Contents/Resources/DWARF/项目名称 -arch arm64 -lbase address(基地址)日志上报的地址
说明:(项目名称.app.dSYM/Contents/Resources/DWARF/项目名称 ) 就是你项目dSYM符号表的完整路径,这是一个文件夹,里面包含一个Contents到Resources到DWARF到你的项目名称的一个文件;(-arch arm64 -l)就是指你分析的是64位的还是以前的armv7类型的机型。
11、下面是友盟上报的日志分析,蓝色中是baseAddress,绿色是自己的堆栈地址,当然绿色我只是标记了一个,上面CFNetwork以上是系统的地址,下面就是自己项目对象的地址,自己项目的地址也是要分析的地址都是自己项目名称开始的,也就是要分析的地址,也就是上面10中的日志上报的地址地址。见下图;
备注:友盟分析不一定准确,个人一般借助dSYMTools再分析下,不过个人感觉友盟分析和atos分析的一致,推测友盟也是用的atos分析的,友盟的话可以上传dSYM文件就可以分析,前段时间我们项目上传不上去,只能通过手动自己分析了,下图就是没有分析友盟上报的堆栈信息,不过最后还是给友盟客服给解决了这个问题。
说明:顺便瞎说下,下面这个bug是CFNetwork里面出错的,原因就是我们在初始化request的时候,没有设置error造成的,因为AFNetwork在网络请求的时候回判断request初始化是否有错误造成的,这段时间一直在解决bug,感觉有的时候写代码整体研发基础太差造成的,会用api,不知道原理造成的。
符号化二进制崩溃问题
文章图片
友盟上传的堆栈图

    推荐阅读