符号化iOS崩溃报告

2015-07-26 本文已影响3925人 iYiming

最近看到一篇关于符号化iOS崩溃报告的文章挺好，决定翻一下，下方链接是原文地址：

https://possiblemobile.com/2015/03/symbolicating-your-ios-crash-reports/

开始

你已经递交你的应用程序的崩溃报告，但是栈回溯包含了难懂的内存地址。开发者该怎么办？简而言之，你需要调试符号来应用于堆栈追踪，从而使它人类可读，这个过程我们称作符号化。

在开始之前，我们依照使用Crasher，它提供了一个简单崩溃报告，让你破译。

你应该有.crash文件。如果没有，你可以从iTunes Connect中攫取，或者直接通过Xcode从连接的设备中攫取（Windows > Devices）,或在一个连接的设备（Settings > Privacy > Diagnostics & Usage）,或使用 PLCrashReporter 框架。你可能已经使用了第三方的崩溃报告服务，在你配置正确后，它将符号化你的崩溃。

根据你的应用创建是如何配置的，你需要一个或者全部下面的东西：

0.导致崩溃的应用程序构建的.app文件。这个包包含了应用二进制文件，以及可能包含测试符号。（如果你有一个.ipa文件，你可以把它当做一个.zip文件，通过解压这个文件把它提取出来）

1.导致崩溃的应用程序构建的.dSYM文件。这是你的应用程序的副产品，包含调试符号化。

你需要哪一个? 在 Xcode中，查找Build Setting里的 "Strip Debug Symbols During Copy"(COPY_PHASE_STRIP)。当允许时，调试符号将会从你的.app省去，把它放到了.dSYM文件。否则你的.app包含这些符号。（默认情况下，由于某些不清楚的原因，调试符号从释放的创建中剥离，你可能不应该改变这个发布配置）

但是等等，什么是调试符号？

为了让调试符号变成人类可读的即程序员给方法命名的名称，编译器通过使用它自己的符号来减少这些命名的调试符号，从而使代码模糊。即使两次相同代码创建，你也不能依赖这些符号。

检查崩溃

如果通过Xcode的Organizer从设备中提交崩溃报告，你的崩溃报告可能将会对UIKit和其他iOS框架自动符号化。如果Xcode知道你的创建，他将自动符号化你的崩溃。

如果不是这种情况，你需要自己符号化。

使用"Symbolicatecrash"工具来符号化

幸运的是，苹果提供给了我们脚本来检索调试符号化，将他们应用于崩溃报告。

对 Xcode 6，你可以在下面目录里找到这个工具：

/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/Current/Resources/symbolicatecrash

或者如果你使用的是Xcode 5 从下方路径获得：

/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/Current/Resources/symbolicatecrash

为了使用这个工具，你需要用安装Xcode恰当路径导出 DEVELOPER_DIR 环境变量：

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

把你的.crash文件.app文件和.dSYM文件放在同一个目录下然后运行：

symbolicatecrash -v ScaryCrash.crash > Symbolicated.crash

你可能需要显示应用应用程序二进制：

symbolicatecrash -v ScaryCrash.crash ./Crasher.app/Crasher > Symbolicated.crash

如果你使用在Crasher例子中发现的便利脚本，需要冗长的标记：

sh symbolicate6.sh ScaryCrash.crash ./Crasher.app/Crasher > Symbolicated.crash

如果你使用在Crasher例子中发现的便利脚本，需要冗长的标记：

sh symbolicate6.sh ScaryCrash.crash ./Crasher.app/Crasher > Symbolicated.crash

验证符号化

如果符号化不能工作，仔细检查你攫取的.dSYM或者.app文件是否正确。你可以通过交叉引用崩溃的报告中的UUID和应用程序二进制中的UUID：

dwarfdump –uuid Crasher.app/Crasher

结果：

1.png

在dSYM文件中：

dwarfdump –uuid Crasher.app.dSYM/Contents/Resources/DWARF/Crasher

结果：

2.png

和你的崩溃报告中的UUID进行比较：

3.png

从symbolicatecrash工具冗长的日志里，同样列出它找出的UUID。

排查 "Symbolicatecrash" 工具

如果你还是困惑，请认真检查symbolication日志。symbolication工具尝试找出你应用中与UUID相匹配的相应文件以及每个动态框架，寻找着你的应用程序名称或者UUID 并看出是否匹配。

4.png

如果Spotlight不能找到你的.dSYM文件，你可能碰到这样一个日志样例：

5.png

或者有一个无效的.dSYM：

6.png

或者有任何其他无效的输入：

7.png

在Xcode 6 版本中的symbolicatecrash工具尝试解决一些再Xcode 5 版本中面临的Spotlight问题。如果你遇到问题，他可能是Spotlight中一个文件的索引问题，尝试：

mdimport -g /Applications/Xcode.app/Contents/Library/Spotlight/uuid.mdimporter .

使用命令行工具链

我们可以深入和使用开发者命令行工具链来一行行的符号化栈追踪的内存地址。如果你在过去使用这个方法中遇到问题，那可能是因为在最近几年.crash文件根式改变了。

首先，让我们再看看我们崩溃报考中的栈追踪：

8.png

最左边的十六进制值，0x000aeef6,是栈地址。第二个十六进制值，0xa8000,是应用程序的加载地址。以加号为开始的数字，28406，是栈地址和加载地址的差值。 0x00aeef6 = 0xa8000 + 0x6EF6
。你将会发现在我们的崩溃报告底部的“Binary Images”，它是动态库内存地址范围列表。我们的二进制文件的起始地址在堆栈跟踪加载地址相匹配。

9.png

下一步，为了更好的测量，我们将验证可执行文件包含蹦溃的架构，不论使用file或者lipo -info命令：

file Crasher.app/Crasher

结果：

10.png

现在我们全副武装。我们经查实atos命令来将我们的地址转换成调试符号。注意我们如何提供加载地址，它在我们指定崩溃的架构的栈地址后面：

atos -arch armv7 -o Crasher.app/Crasher -l 0xa8000 0x000aeef6

结果：

11.png

就是这样。如果你有兴趣继续钻研，研读Mach-O对象文件格式以及Mach-O命令行实用工具，也就是otool和lipo命令。