命令行工具atos解析iOS app的崩溃日志(bugly)

1.找到应用打包生成的 appName.dYSM 文件(appName是你的应用的名称)；
2.打开终端，执行命令xcrun atos -o appName.app.dSYM/Contents/Resources/DWARF/appName -l 模块加载地址 第二个地址

xcrun atos -o appName.app.dSYM/Contents/Resources/DWARF/appName -l 0x0000000102c74000

其中地址0x0000000102c74000叫做模块加载地址，
3.然后，继续输入地址，这个地址对应bugly错误堆栈的位置如下图示，
0x0000000102e89148
解析得到：

video_data_callback (in appName) (MyObjectiveCClass.m:0)

bugly出错堆栈信息.png

终端解析错误信息.png

参考文献链接：
1.使用命令行工具 atos 解析 iOS app 的错误（崩溃）日志
2.分析iOS Crash文件：符号化iOS Crash文件的3种方法

参考文献原文：
准备工作：
1.有一个app的奔溃日志文件：appName.crash
2.找到对应的应用，打包生成 appName.app appName.dYSM 文件，将这两个文件和 .crash文件放在同一个目录下

开始查找：

1.找到报错的语句，记录appName 那一行的第一个地址：

使用命令行工具 atos 解析 iOS app 的错误（崩溃）日志

如上图所示，地址为 0x00000001000ece74

2.打开命令行，cd 进准备工作中的目录，使用

grep “appName arm” *crash

或

grep —after-context=2 “Binary Images:” *crash

查找crash模块的加载地址，得到的结果如下：

使用命令行工具 atos 解析 iOS app 的错误（崩溃）日志

这里的 0x1000d0000 就是加载地址, arm64 是 architecture 的值，这两个值后面都要用

3.用atos命令来符号化某个特定的模块加载地址：

xcrun atos -o appName.app.dSYM/Contents/Resources/DWARF/appName -l 0x1000d0000 -arch arm64

输入完这个命令后如果没有报错，会进入到一个带输入状态，
此时输入第1步得到的地址：0x00000001000ece74
就会出现类似下面的情况：

使用命令行工具 atos 解析 iOS app 的错误（崩溃）日志

这张图可以很明确地表明哪里出了错。