版本记录

版本号	时间
V1.0	2021.11.20 星期六

前言

程序总会有bug，如果有好的调试技巧和方法，那么就是事半功倍，这个专题专门和大家分享下和调试相关的技巧。希望可以帮助到大家。感兴趣的可以看下面几篇文章。
1. 程序调试 （一） —— App Crash的调试和解决示例（一）
2. 程序调试 （二） —— Xcode Simulator的高级功能（一）
3. 程序调试 （三） —— Xcode Simulator的高级功能（二）
4. 程序调试 （四） —— Xcode内存管理（一）
5. 程序调试 （五） —— 使用Build Configurations 和 .xcconfig 构建你的App（一）
6. 程序调试 （六） —— 使用Build Configurations 和 .xcconfig 构建你的App（二）
7. 程序调试 （七） —— 基于iOS的Charles Proxy教程（一）
8. 程序调试 （八） —— 基于iOS的高级Charles Proxy教程（一）
9. 程序调试 （九） —— Crash日志的获取和符号解析（一）

开始

上面一篇程序调试 （九） —— Crash日志的获取和符号解析（一）我们介绍了崩溃的解析。

那个是使用了symbolicatecrash进行dSYM包进行反解析。下面我们看另外一个方法。

首先我们还是看下未解析过的崩溃日志。

这里需要注意一下，红色框框里面的就是我的App相关的崩溃信息。特别要注意地址0x0000000106371584 0x100ffc000。其中0x100ffc000是程序基地址，0x0000000106371584是方法的堆栈地址。

接着找到一个dSYM包，右击并选择显示包内容。

可以看见下面的文件目录

下面我们不用symbolicatecrash进行dSYM包进行反解析，直接用命令行进行解析下。

在终端进入到dSYM的路径

输入下面指令

dwarfdump --uuid xxx.app.dSYM

可以得到下面输出

可以看见是arm64结构的。

下面继续输入

//xxx就是自己app包名
atos -arch arm64 -o  xxx.app.dSYM/Contents/Resources/DWARF/xxx -l 0x100ffc000 0x0000000106371584

看下面的输出

可以看见是崩溃在C++了。但是看不出来具体是咋回事，这里只是讲述了一种方法，虽然这里还看不出来原因。下面我们就用symbolicatecrash进行dSYM包进行反解析来验证这个方法的输出是否正确。

symbolicatecrash反解析出来如下所示：

这就反向证明，上面那个方法解析也是可以的。

后记

本篇主要讲述了Crash日志的另外一种解析方法，感兴趣的给个赞或者关注~~~