符号化二进制崩溃问题

符号化二进制崩溃问题

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中间中的UUID和crash文件的UUID进行对比，如果不一样的话，说明不是这个版本造成的crash直接继续再找吧。

备注：以上7~9是真机crash日志的分析，三方堆栈分析见下面

10、关于其他三方上传的堆栈地址的时候，用atos分析，命令如下：

atos -o 项目名称.app.dSYM/Contents/Resources/DWARF/项目名称 -arch arm64 -l  base 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，不知道原理造成的。

友盟上传的堆栈图