0%

iOS崩溃日志堆栈解析

iOS崩溃日志堆栈解析

本文只为自己查看方便.

.dSYM 文件

我们调试的 symbols 会包含在这个文件中。

每次编译项目的时候都会生成一个新的 dSYM 文件,我们应该保存每个正式发布版本的 dSYM 文件,以备我们更好的调试问题。一般是在我们 Archives 时保存对应的版本文件的,里面也有对应的 .dSYM 和 .app 文件。

符号解析

注意:.dSYM 、.crash文件,二者的UUID必须一致解析才有意义.

获取 UUID

.crash UUID

grep --after-context=2 "Binary Images:" *crash

.dSYM UUID

dwarfdump --uuid myCrashDemo.app.dSYM

.app UUID

dwarfdump --uuid myCrashDemo.app/myCrashDemo

使用symbolicatecrash进行解析

symbolicatecrash 是 Xcode 自带的 crash 日志分析工具.

首先查找到它的路径:

find /Applications/Xcode.app -name symbolicatecrash

把 symbolicatecrash 拷贝出来,放到一个文件夹下。

有两种方式解析:

  1. symbolicatecrash + .dSYM + .crash
  2. symbolicatecrash + .app + .crash

利用 dSYM

将 .dSYM 、.crash 及 symbolicatecrash 放到同一个文件下,执行命令:

./symbolicatecrash .crash文件路径 .dSYM文件路径 > 名字.crash

利用 app

将 .app 、.crash 及 symbolicatecrash 放到同一个文件下,执行命令:

./symbolicatecrash .crash文件路径 .app/appName 路径 > 名字.crash

可能会报错误:

Error: "DEVELOPER_DIR" is not defined at ./symbolicatecrash line 69.

执行下命令就行:

export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer

然后再重新生成下新的 .crash 文件就行。

使用命令行工具 atos

同样也有两种方式

  1. .dSYM + .crash
  2. .app + .crash

.dSYM方式

xcrun atos -o ./myCrashDemo.app.dSYM/Contents/Resources/DWARF/myCrashDemo -arch 指令集(armv7或arm64) -l Slide地址

接着输入错误的内存地址,即可看到.

.app方式

xcrun atos -o myCrashDemo.app/myCrashDemo -arch 指令集(armv7或arm64) -l Slide地址

接着输入错误的内存地址.

GitHub 上有个dSYMTools工具封装了atos命令,可以辅助我们解析.

使用很方便,只要拖入dSYM文件,然后将错误地址以及Slide Address输入工具的文本框中即可.

Slide address查看

在崩溃日志里面找到 Binary IImages: 这一块,Binary IImages: 下面第一行就是加载应用可执行文件的信息,大致如下:

1
2
3
4
5
6
7
Binary Images:
0x100878000 - 0x10087ffff myCrashDemo arm64 <dc8bc710db863d2ca08180537af8015e> /var/containers/Bundle/Application/3BCB5A1C-9BD8-44CD-84EE-39128C005B9F/myCrashDemo.app/myCrashDemo
0x100938000 - 0x10099bfff dyld arm64 <fc36be383ccf330abe42940868e68937> /usr/lib/dyld
0x102478000 - 0x102483fff libobjc-trampolines.dylib arm64 <a8cd788cc9113887ae254bd47d58c7c1> /usr/lib/libobjc-trampolines.dylib
0x239546000 - 0x239547fff libSystem.B.dylib arm64 <b3dbcc8e41b03e51b7e65d2800dcdea9> /usr/lib/libSystem.B.dylib
0x239548000 - 0x2395a2fff libc++.1.dylib arm64 <c406443c983a33829b164c441b7c2af4> /usr/lib/libc++.1.dylib
...

其中 0x100878000 就是 slide address。
arm64 指的是 arm64 架构下,uuid 是 dc8bc710db863d2ca08180537af8015e.

错误的内存地址查看

内存地址是 Last Exception Backtraces 中每一行的第一个地址,分析其他行的时候你要看下是不是自己应用可执行文件那行,因为你这个 slide address 只对应到自己那个可执行文件,系统的一些库的 slide address 都不一样的。
其实分析一个 crash 文件并不要很长时间,只需要找到自己可执行文件对应的那行内存地址,slide address,和 arch type 这三个信息就可以了,并不是每一行错误信息都需要看。

觉得文章有帮助可以打赏一下哦!