dSYM文件分析

dSYM 文件

什么是 dSYM 文件

Xcode编译项目后，我们会看到一个同名的 dSYM 文件，dSYM 是保存 16 进制函数地址映射信息的中转文件，我们调试的 symbols 都会包含在这个文件中，

并且每次编译项目的时候都会生成一个新的 dSYM 文件，位于 /Users/beyond/Library/Developer/Xcode/Archives 目录下，

对于每一个发布版本我们都很有必要保存对应的 Archives 文件 。

dSYM 文件有什么作用

当我们软件 release 模式打包或上线后，不会像我们在 Xcode 中那样直观的看到用崩溃的错误，这个时候我们就需要分析 crash report 文件了，

iOS 设备中会有日志文件保存我们每个应用出错的函数内存地址，

通过 Xcode 的 Organizer 可以将 iOS 设备中的 DeviceLog 导出成 crash 文件，这个时候我们就可以通过出错的函数地址去查询 dSYM 文件中程序对应的函数名和文件名。

大前提是我们需要有软件版本对应的 dSYM 文件，这也是为什么我们很有必要保存每个发布版本的 Archives 文件了。

如何将文件一一对应

每一个 xx.app 和 xx.app.dSYM 文件都有对应的 UUID，crash 文件也有自己的 UUID，只要这三个文件的 UUID 一致，我们就可以通过他们解析出正确的错误函数信息了。

1.查看 xx.app 文件的 UUID，terminal 中输入命令 ：

dwarfdump --uuid xx.app/xx (xx代表你的项目名)

2.查看 xx.app.dSYM 文件的 UUID ，在 terminal 中输入命令：

dwarfdump --uuid xx.app.dSYM 

3.crash 文件内第一行 Incident Identifier 就是该 crash 文件的 UUID。

要分析崩溃日志，首先需要保留发布时的编译出来的.xcarchive文件。这个文件包含了.DSYM文件。

我一般的做法是，发布成功后，把这个文件.xcarchive直接提交到代码版本库对应的版本分支里，这样就不会搞丢了。

这个文件在哪呢？打开XCode->菜单Window->Organizer，在编译成功的文件上右键，就能打开了。

两种比较麻烦的方法。

第一种方法：

使用dwarfdump命令

dwarfdump --uuid xx.app.dSYM     用来得到app的UUID。
dwarfdump --lookup 0x100445290 -arch armv7 xx.app.dSYM  使错误的日志能看懂，把相应的内存地址对应到正确的地方。
如果一开始dwarfdump命令不能用的话，要先装Command Line Tools,这个在设置里面能下载（cmd+“，”打开设置）。另外还必须在进入.DSYM所在文件夹。

使用dwarfdump需要安装Command Line Tools,XCode里设置下载。而且需要进入.DSYM所在文件夹里进行操作。

第二种方法：

使用xcrun atos命令

命令：atos -o YourApp.app.dSYM/Contents/Resources/DWARF/YourApp 0x出错地址

Application received signal SIGSEGV
(null)
(
	0   CoreFoundation                      0x00000001848270b8+ 160
	1   libobjc.A.dylib                     0x00000001907a5d78 objc_exception_throw + 60
	2   CoreFoundation                      0x0000000184826fdc+ 0
	3   JZH 0x1001d12f8 JZH + 1905400
	4   libsystem_platform.dylib            0x0000000190f07b0c _sigtramp + 56
	5   JZH 0x100445290 _ZN12CAXExceptionC2EPKci + 187764
	6   libsystem_pthread.dylib             0x0000000190f0c1b0+ 168
	7   libsystem_pthread.dylib             0x0000000190f0c108+ 0
	8   libsystem_pthread.dylib             0x0000000190f097b0 thread_start + 4
)

dSYM UUID: 981FC7CB-FC3F-351F-9C8E-88248232294B
CPU Type: arm64
Slide Address: 0x0000000100000000
Binary Image: JZH
Base Address: 0x00000001000d4000

命令：atos -o JZH.app.dSYM/Contents/Resources/DWARF/JZH 0x100445290

   CheckPrivateCloud(void*) (in JZH) (CCPClient.cpp:488)

命令：dwarfdump --lookup 0x100445290  -arch arm64 JZH.app.dSYM

命令：atos -o JZH.app.dSYM/Contents/Resources/DWARF/JZH 0x1001d12f8

   UmengSignalHandler (in JZH) + 144

命令：dwarfdump --lookup 0x1001d12f8 -arch arm64 JZH.app.dSYM

Application received signal SIGSEGV
(null)
(
	0   CoreFoundation                      0x255af0ef+ 150
	1   libobjc.A.dylib                     0x33a41c77 objc_exception_throw + 38
	2   CoreFoundation                      0x255af01d+ 0
	3   JZH 0x1a4711 JZH + 1705745
	4   libsystem_platform.dylib            0x3415109b _sigtramp + 34
	5   libstdc++.6.dylib                   0x33e3461b _ZNSs12_S_constructIPKcEEPcT_S3_RKSaIcESt20forward_iterator_tag + 70
	6   libsystem_pthread.dylib             0x34155ddf+ 138
	7   libsystem_pthread.dylib             0x34155d53 _pthread_start + 118
	8   libsystem_pthread.dylib             0x34153afc thread_start + 8
)

dSYM UUID: 53B95E22-1D47-31C8-9452-41875FFC7F89
CPU Type: armv7
Slide Address: 0x00004000
Binary Image: JZH
Base Address: 0x00004000

命令：atos -o JZH.app.dSYM/Contents/Resources/DWARF/JZH 0x1a4711

   UmengSignalHandler (in JZH) + 137

命令：dwarfdump --lookup 0x1a4711 -arch armv7 JZH.app.dSYM

目录下一定要包含MyApp.app 和MyApp.app.dSYM两个文件。

在控制台使用dwarfdump命令，解析出内存地址，如：

dwarfdump –lookup 0x000036d2 –arch armv6 MyApp.app.dSYM

つづく