[iOS开发]iOS 符号表dSYM

一、符号表

1、概念：debugger Symbols 的简称。符号表就是指在Xcode项目编译后，在编译生成的.app的同级目录下生成的同名的.dSYM文件。
符号表是内存地址与函数名，文件名，行号的映射表。 符号表元素如下所示:

<起始地址> <结束地址> <函数> [<文件名:行号>]

.dSYM文件其实是一个目录，在子目录中包含了一个16进制的保存函数地址映射信息的中转文件，所有Debug的symbols都在这个文件中(包括文件名、函数名、行号等)，所以也称之为调试符号信息文件。

2、作用：符号表就是用来符号化 crash log（崩溃日志）。crash log中有一些方法16进制的内存地址等，通过符号表就能找到对应的能够直观看到的方法名之类。

3、获取途径：在Archive的时候会生成.xcarchive文件，然后显示包内容就能够在里面找到.dsYM文件和.app文件。

  • 一般Xcode项目每次编译后, 都会产生一个新的.dSYM文件和.app文件, 这两者有一个共同的UUID.
  • 注:项目编译完dSYM文件和app文件在同一个目录，Xcode Debug 编译默认不会生成.dSYM文件, Release 编译才会生成
  • 注:为了方便找回Crash对应的dSYM文件和还原堆栈，建议每次构建或者发布APP版本的时候，备份好dSYM文件。

二、符号化文件

1、 Xcode分析

1>、要使用Xcode符号化 crash log，你需要下面所列的3个文件：
①crash报告（.crash文件）
②符号文件 (.dsymb文件)
③应用程序文件 (.app文件）

2>、把这3个文件放到同一个目录下，打开Xcode的Window菜单下的organizer，然后点击Devices tab，然后选中左边的Device Logs。
然后把.crash文件拖到Device Logs或者选择下面的import导入.crash文件。
这样你就可以看到crash的详细log了。

2、使用命令行工具symbolicatecrash

1>、将“.app“, “.dSYM”和 ".crash"文件放到同一个目录./Crash 下。
2>、在Xcode中找到 symbolicatecrash 工具

使用命令

find /Applications/Xcode.app -name symbolicatecrash -type f

可以轻松找到。找到后你会发现有多个其中

/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash

对应的是真机, 找到后将 symbolicatecrash 拷贝到 ./Crash 目录下

3>、切换到 ./Crash目录下。 打开终端(Terminal)然后输入如下的命令：

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

然后输入命令：

./symbolicatecrash appName.crash appName.app > appName.log

现在，符号化的crash log就保存在appName.log中了。

如果报No such file or directory : at ./symbolicatecrash line 909.错误，尝试执行

./symbolicatecrash ./*.crash ./*.app.dSYM>Symbol_Crash.crash

3、atos

  • atos 是一个可以把地址转换为函数名（包括行号）的工具, 它和dwarfdump 为mac os自带工具.
    我们使用atos命令来完成符号化，具体命令如下：
    $ atos -arch <Binary Architecture> -o <Path to dSYM file>/Contents/Resources/DWARF/<binary image name> -l <load address> <address to symbolicate>

其中:

  • Binary Architecture: arm64、armv6、armv7 armv7s 根据自己的情况来写。
  • Path to dSYM file: dSYM文件的路径。
  • binary image name: 你工程的名字。
  • load address: 是运行时起始地址（基地址），如果我们的崩溃日志中没有这个信息(比如上面的Crash信息中就没有包含)，就需要我们手动去计算这个load * address:laod address = address to symbolicate - offset,比如：0x0000000102838119转化为十进制为4337139993,再减去偏移量265,为4337139728,在转化为十六进制0x0000000102838010
  • address to symbolicate:运行时堆栈地址，当前方法的内存地址。

具体示例：
atos -arch arm64 -o CrashDemo.app.dSYM/Contents/Resources/DWARF/CrashDemo -l 0x0000000102838010 0x0000000102838119

这样crash文件就被符号化完成了，打开符号化如下图：

三、Crash分析

以上图为例，大部分字段都是不言而喻的，下面列举一些有用处的。（在官方文档都有解释，这里做归纳与翻译）

Incident Identifier： 报告的唯一标识符，两份报告决不会共享同一个事件标识符。
CrashReporter Key：每个设备的匿名标识符，来自同一设备的两个报告将包含相同的值。
Process：很明显是我们的进程名称。
Date/Time 与 Launch Time：报告生成时间与程序开始运行时间
Exception Type：异常类型
Exception Note：不属于异常类型的附加信息，如果这个字段包含SIMULATED(不是崩溃)，那这个进程不是崩溃的，而是在系统的请求下被杀死，通常是看门狗机制起了作用（APP内一段时间内无法响应用户的操作，会被系统kill）。
Termination Reason：闪退的原因，比如常见的数组越界啊，什么的。
Triggered by Thread：出现问题在哪个线程，这个比较重要，首先确定在哪个线程中出了问题，然后再去定位。
接着是最重要的堆栈信息，由下到上为最后调用的顺序：

image

可以很明显的看到，一个名为ViewController的对象在viewDidLoad方法中调用了第35行的testMethodTwo方法，并执行testMethodTwo方法中的61行时代码，在Backtrace第2行可以发现调用了未识别的方法导致崩溃，我们来看下代码。

最终我们找到了崩溃的原因：一个NSArray调用了addObject方法，so easy!

一些较常见的异常类型（如果翻译错误请指正）：

内存访问不良[EXC_BAD_ACCESS // SIGSEGV // SIGBUS]

通常用于访问了不该访问的内存导致或者尝试以不允许的方式访问内存（例如只读属性，比如在上一篇我们提到的通过KVO更改只读属性），并且" Exception SubType"字段会包含kern_return_t来描述错误和未正确访问的内存地址。
下面是官方给出的建议：

  • 如果objc_msgSend或objc_release接近崩溃线程的Backtraces(堆栈信息回溯)的顶部，则该进程可能试图向释放的对象发送消息，可以使用Zombie Instrument来分析应用程序，以更好地了解此次崩溃的情况。
  • 如果gpus_ReturnNotPermittedKillClient接近崩溃线程的Backtraces的顶部，则该进程被终止，因为它尝试在后台使用OpenGL ES或Metal进行渲染。
异常退出[EXC_CRASH // SIGABRT]

该进程异常退出，此异常类型崩溃的最常见原因是向对象发送了无法识别的消息，比如上文中向NSArray发送了addObject消息。
另外如果App Extensions需要太多时间来初始化（看门狗机制），那么App Extensions将终止于此异常类型，如果扩展因启动时挂起而死亡，则生成的崩溃报告的Exception Subtype将会是LAUNCH_HANG，由于扩展没有main函数，任何花在初始化上的时间都会在+load扩展库和相关库中的静态构造函数和方法中，你应该尽可能多地推迟这项工作。

资源限制[EXC_RESOURCE]

该过程超出了资源消耗限制，这是来自操作系统的通知，该进程正在使用太多的资源,确切的资源列在Exception SubType字段中。如果Exception Note字段包含NON-FATAL CONDITION，则即使生成崩溃报告，该进程也不会被终止。

  • 异常子类型MEMORY表示该进程已超过系统施加的内存限制。
  • 异常子类型WAKEUPS表示进程中的线程每秒被唤醒的次数过多，这迫使CPU醒来的频率很高，并且消耗电池寿命。

四、符号化dSYM常见问题

如何查看dsYM文件的UUID?

方法一： 通过命令行查看dSYM文件的UUID

 xcrun dwarfdump --uuid <dSYM文件>

方法二：通过符号表文件查看UUID
符号表文件的UUID与dSYM文件的UUID是一致的，因此可以通过符号表工具生成的符号表文件来查看dSYM文件的UUID：
生成符号表文件(.zip) ---> 解压符号表文件(.symbol) ---> 使用文本编辑器打开符号表文件

其中符号表文件的“UUID”信息即Debug SO文件的UUID，亦是符号表文件的UUID，如果文件较大，建议使用“Sublime Text”等文本编辑器来打开符号表文件。

如何定位dSYM文件？

一般情况下，项目编译完dSYM文件跟app文件在同一个目录下，下面以XCode作为IDE详细说明定位dSYM文件。

-> 进入XCode；
-> 打开工程（已编译过）；
-> 在左栏找到“Product”项；
-> 鼠标右键点击编译生成的“xxx.app”；
-> 点击“Show in Finder”；

如下图所示：

如果有多个dSYM文件，可以在使用工具时指定输入为dSYM文件所在的目录或者工程目录。

Xcode编译后没有生成dSYM文件？

XCode Release编译默认会生成dSYM文件，而Debug编译默认不会生成，对应的Xcode配置如下：

XCode -> Build Settings -> Code Generation -> Generate Debug Symbols -> Yes

XCode -> Build Settings -> Build Option -> Debug Information Format -> DWARF with dSYM File

image.png

开启Bitcode之后需要注意哪些问题？

  • 在点“Upload to App Store”上传到App Store服务器的时候需要声明符号文件（dSYM文件）的生成：


  • 在配置符号表文件之前，需要从App Store中把该版本对应的dSYM文件下载回本地（参考“如何找回已发布到App Store的App对应的dSYM文件？”），然后用符号表工具生成和上传符号表文件。

  • 不需要配置自动生成符号表的脚本了，也不要用本地生成的dSYM文件来生成符号表文件，因为本地编译生成的dSYM文件的符号表信息都被隐藏了。如果用本地编译生成的dSYM文件生成符号表文件并配置到Bugly平台之后，还原出来的结果将是类似于“__hiden#XXX”这样的符号。

如何判断dSYM文件是否与Crash的UUID匹配？

Bugly还原Crash堆栈时，需要根据UUID来匹配符号表文件，因此只有上传的符号表文件的UUID与Crash对应APP的UUID一致时，才能准确地对堆栈进行还原。

  • 查看符号表文件的UUID（“如何查看dSYM文件的UUID？”）

  • 查看Crash对应的APP的UUID

如何找回已发布到App Store的App对应的dSYM文件？

1> 通过Xcode找回
  1. 打开 Xcode 顶部菜单栏 -> Window -> Organizer 窗口：
  1. 打开 Xcode 顶部菜单栏，选择 Archive 标签：

  1. 找到发布的归档包，右键点击对应归档包，选择Show in Finder操作：


  2. 右键选择定位到的归档文件，选择显示包内容操作：

  1. 选择dSYMs目录，目录内即为下载到的 dSYM 文件：
2>通过mdfind工具找回

在Bugly的issue页面查询到crash对应的UUID：

然后在Mac的Shell中，用mdfind命令定位dSYM文件：

mdfind "com_apple_xcode_dsym_uuids == <UUID>"

注意，使用mdfind时，UUID需要格式转换（增加“-”）： 12345678-1234-1234-1234-xxxxxxxxxxxx

例如，要定位的dSYM的UUID为：E30FC309DF7B3C9F8AC57F0F6047D65F 则定位dSYM文件的命令如下：

mdfind "com_apple_xcode_dsym_uuids == E30FC309-DF7B-3C9F-8AC5-7F0F6047D65F"
                                     |12345678-1234-1234-1234-xxxxxxxxxxxx|

建议每次构建或者发布APP版本的时候，备份App对应的dSYM文件！

参考:
iOS开发符号表(dSYM)知识总结
bugly文档
iOS Crash收集与分析详解（基础篇）
iOS Crash监测及处理上传

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 156,423评论 4赞 359
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 66,339评论 1赞 289
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 106,241评论 0赞 237
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 43,503评论 0赞 203
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 51,824评论 3赞 285
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 40,262评论 1赞 207
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 31,615评论 2赞 309
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 30,337评论 0赞 194
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 33,989评论 1赞 238
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,300评论 2赞 240
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,829评论 1赞 256
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 28,193评论 2赞 250
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 32,753评论 3赞 230
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,970评论 0赞 8
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,708评论 0赞 192
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 35,295评论 2赞 267
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 35,207评论 2赞 258