Xcode - UUID 与框架 dSYM 不匹配

Posted 2023-02-22

【中文标题】Xcode - UUID 与框架 dSYM 不匹配

【英文标题】：Xcode - UUID mismatch with framework dSYMs

【发布时间】：2013-01-29 10:17:06

【问题描述】：

我有一个 OSX 桌面 Xcode 项目，其中包含另一个 Xcode 项目（一个框架）作为依赖项。当我构建应用程序的存档时，它会生成两个 dSYM 包 - 一个用于应用程序，一个用于框架。

当我表示从应用程序接收到的崩溃时，应用程序包中的符号会正确显示（带有文件名和行号）。然而，来自框架的符号根本不象征——它们只是显示框架名称和内存地址。有没有办法对涉及框架代码的堆栈跟踪部分进行符号化？

查看我从中生成 .app 包的存档，框架的 dSYM 的 UUID 与复制到 .app 中的“Frameworks”文件夹中的 UUID 不匹配：

归档文件中.app包内的HCCommon框架：

/path/to/HipChat.xcarchive $ dwarfdump --uuid Products/Applications/HipChat.app/Contents/Frameworks/HCCommon.framework/HCCommon 
UUID: 84891A9C-19DB-3E16-BE7E-9D4056FFFB97 (x86_64) Products/Applications/HipChat.app/Contents/Frameworks/HCCommon.framework/HCCommon

vs HCCommon 框架的 dSYM（在归档文件中的 dSYMs 目录中）：

/path/to/HipChat.xcarchive $ dwarfdump --uuid dSYMs/HCCommon.framework.dSYM/Contents/Resources/DWARF/HCCommon 
UUID: 767F2D97-9E0B-3C4D-8337-FDF5A9CA2D81 (x86_64) dSYMs/HCCommon.framework.dSYM/Contents/Resources/DWARF/HCCommon

【参考方案1】：

我不确定为什么您的构建会导致 dSYM UUID 不一致。当我们进行这些类型的构建时（现在已经抽查了一些），我们有一致的 UUID。

但是，在回答您的问题时，关于如何根据您已经拥有的 .dSYM 来表示您已经收到的崩溃报告（假设目前虽然 UUID 匹配，但它们引用相同的代码，因此将工作）。

如果您必须强制使用特定的 dsym，我发现以下方法可以正常工作：

atos -arch x86_64 -o <path_to_dsym_within_package> -l <offset_of_framework>

当然没有那么漂亮，通常我通过 atos 手动运行各个地址，但结果是有效的例程/行组合（假设您匹配正确的版本等）

<path_to_dsym_within_package> 指的是foo.framework.dSYM/Contents/Resources/DWARF/foo，后跟您的二进制名称，其中foo 是框架的名称。对我们来说，这也适用于任何类型的插件。

<offset_of_framework> 来自崩溃日志中的偏移列，其中：

0 libsystem_kernel.dylib 0x7fff8e785ce2 0x7fff8e76f000 + 93410
1 libsystem_c.dylib 0x7fff871afa7a 0x7fff8716e000 + 268922
2 CTUtils 0x104e26c62 0x104e17000 + 64610

在这种情况下，第一个十六进制数字是地址，第二个十六进制数字是特定框架的起始偏移量，+ 值是框架内的十进制偏移量。

您需要上面命令行的第二个数字（十六进制偏移量），以及第一个数字来查找特定的例程/行号。

在最坏的情况下，总是直接使用dwarfdump，通过使用：

dwarfdump <path_to_dSYM> --arch x86_64 --lookup <offset>

<path_to_dSYM> 是***“.dSYM”文件夹的路径（与上面的atos 命令不同），<offset> 是模块内的偏移量，不如atos 方便。

附：如果你安装了开发工具，atos 应该安装在/usr/bin/atos 中。

【参考方案2】：

我也遇到过这个问题。经过一番调查，事实证明 Xcode 正在将 debug 框架构建复制到发布构建中，但显然是从正确的发布二进制文件创建 dSYM。

尽管使用 Xcode 从工作区添加框架依赖项，但仍然如此。最终我发现了原因：由于某种原因，框架被包含在项目中，它们的位置为“相对于组”。在我确定所有都是“相对于构建产品”之后，它为我解决了这个问题。并不是说这是唯一可能的原因，但值得仔细检查构建日志中的所有路径，因为在这种情况下 Xcode 不会发出任何警告。