【问题标题】:How to symbolicate crash log Xcode?如何符号化崩溃日志 Xcode?
【发布时间】:2014-11-09 09:54:52
【问题描述】:

Xcode 5 组织者有一个视图可以列出所有的崩溃日志。我们可以在这里拖放崩溃日志。但是从 Xcode 6 开始,我知道他们已经将设备从组织中移出,并且有一个新的窗口。但是我没有找到一个地方可以查看我在升级到 Xcode 6 后拖放到 Xcode 5 中的崩溃日志。有人知道答案吗?

【问题讨论】:

  • 几个月前我在Apple developer forums 上问过这个问题,但从未得到答案。这是有用功能的损失。向 Apple 提交错误报告,要求恢复此功能。
  • 我在一个周末拼凑起来解决 iOS 和 OSX 故障转储的符号化问题。它仍然很粗糙,但它应该可以工作。 github.com/agentsim/Symbolicator
  • Xcode,你能不能像你应该的那样从 Apple 审阅者那里得到象征性的崩溃日志......而不是假设我们真的有一整天的时间来弄清楚如何做到这一点?

标签: ios xcode


【解决方案1】:

为社区和我自己写这个答案。

如果在表示崩溃报告时遇到问题,可以通过以下方式解决:

  1. 创建一个单独的文件夹,将Foo.appFoo.app.dSYM从对应的.xcarchive复制到文件夹中。同时将.crash 报告复制到文件夹中。

  2. 在 TextEdit 或其他地方打开崩溃报告,转到Binary Images: 部分,然后将第一个地址复制到那里(例如0xd7000)。

  3. cd 进入文件夹。现在您可以运行以下命令:

    xcrun atos -o Foo.app/Foo -arch arm64 -l 0xd7000 0x0033f9bb

这将象征地址0x0033f9bb 处的符号。请确保为-arch 选项选择正确的值(可以从Binary Images: 部分的第一行中获取,或从崩溃报告中的Hardware Model: 和应用程序支持的拱门中找出)。

您还可以将崩溃报告中的必要地址(例如线程调用堆栈)直接复制到文本文件中(在 TextEdit 中,按住 Option 并选择必要的文本块,或复制并剪切),以获得类似这样的内容:

0x000f12fb
0x002726b7
0x0026d415
0x001f933b
0x001f86d3

现在您可以将其保存到文本文件中,例如addr.txt,然后运行以下命令:

xcrun atos -o Foo.app/Foo -arch arm64 -l 0xd7000 -f addr.txt

这将同时为所有地址提供一个很好的符号。

附言

在执行上述操作之前,有必要检查所有设置是否正确(因为atos 会很乐意为基本上任何提供的地址报告一些内容)。

要进行检查,请打开崩溃报告,然后转到 Thread 0 的调用堆栈末尾。从末尾开始的第一行列出您的应用(通常是第二行),例如:

34  Foo                    0x0033f9bb 0xd7000 + 2525627

应该是main() 电话。如上所述用符号表示地址(在这种情况下为0x0033f9bb)应该确认这确实是main(),而不是一些随机的方法或函数。

如果地址不是main()的地址,请检查你的加载地址(-l选项)和arch(-arch选项)。

附言

如果由于 bitcode 导致上述操作无效,请从 iTunes Connect 下载构建的 dSYM,从 dSYM 中提取可执行二进制文件(Finder > Show Package Contents),将其复制到目录,并将其(即Foo)用作atos 的参数,而不是Foo.app/Foo

【讨论】:

  • 感谢您编写迷你 xcrun 教程并使用健全性检查部分对其进行更新。经过大量的咒骂并且看不到任何象征性,我的理智得到了拯救
  • 不要忘记验证崩溃报告是否与可执行文件和 dSYM 匹配。您可以通过运行 xcrun dwarfdump --uuid <path to executable> 将二进制图像部分下 中的标识符与从可执行文件返回的标识符进行匹配来检查这一点
  • 请务必注意,只有来自您的应用 (Foo) 的符号才会显示。它不会显示来自外部库/框架(例如 Foundation 或 libsystem_kernel.dylib)的符号。
  • 这很有帮助,但对我仍然不起作用。我遇到问题的部分是我没有 0xd7000 信息。我的行看起来像这样 0x100038328 __mh_execute_header + 99112。我已经读过 __mh_execute_header 是什么,但我怎样才能获得关于 0x100038328 的信息?我什么都有
  • 我编写了一个简单的 bash 脚本,它可以为您完成大部分工作。用法:./symbolicate.sh mycrash.crash MyApp.app arch64 output.crash 只有它会符号化完整的崩溃报告并给你它的符号化版本。 gist.github.com/nathan-fiscaletti/…
【解决方案2】:

你也可以参考这个,我已经写了Manual Crash Re-Symbolication的逐步过程。

Crash Re-Symbolication

第 1 步

将上述所有文件(MyApp.app、MyApp-dSYM.dSYM 和 MyApp-Crash-log.crash)移动到一个名称方便的文件夹中,您可以轻松地使用终端。

对我来说,桌面是最容易到达的地方;) 所以,我将这三个文件移到了桌面的 MyApp 文件夹中。

第 2 步

现在轮到 Finder,从适用于您的 XCODE 版本的路径转到路径。

使用此命令查找symbolicatecrash 脚本文件,
find /Applications/Xcode.app -name symbolicatecrash

Xcode 8、Xcode 9、Xcode 11 /Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash

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

XCode 7 /Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash

Xcode 6 /Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources

低于 Xcode 6 Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources

或者 Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources

第 3 步

将找到的 symbolicatecrash 脚本文件的目录添加到 $PATH 环境变量,如下所示:sudo vim /etc/paths.d/Xcode-symbolicatecrash 并粘贴脚本文件的目录并保存文件。打开新终端时,可以在任意文件夹调用symbolicatecrash,作为/usr/bin中的命令。

或者

从该位置复制 symbolicatecrash 文件,并将其粘贴到桌面/MyApp (等等……不要盲目关注我,我正在将 sybolicatecrash 文件粘贴到 MyApp 文件夹中,这是您在第一步中在您最喜欢的位置创建的一个,包含三个文件。)

第 4 步

打开终端,然后 CD 到 MyApp 文件夹。

cd Desktop/MyApp — Press Enter
export DEVELOPER_DIR=$(xcode-select --print-path)

 — 回车

./symbolicatecrash -v MyApp-Crash-log.crash MyApp.dSYM

 — 回车

就是这样!!符号化的日志在您的终端上…… 现在你还在等什么?现在简单地说,找出错误并解决它;)

【讨论】:

  • 使用导出 DEVELOPER_DIR=xcode-select --print-path
  • 辛苦了 - 谢谢。只有一件事我必须使用 export DEVELOPER_DIR=/Applications/XCode.app/Contents/Developer (不带引号)。
  • "export DEVELOPER_DIR=xcode-select --print-path" 只是告诉我"-bash: export: `--print-path': not a valid identifier
  • 更新;这里是 ;对于 xcode7 在这里找到 symbolicatecrash ; /Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash /Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash 每stackoverflow.com/questions/32804611/…跨度>
  • hm,它只象征着一切除了我的应用程序目标的符号我为...提供了dsym...
【解决方案3】:

好的,我意识到你可以这样做:

  1. Xcode > Window > Devices,左上角选择一个已连接的iPhone/iPad/等。
  2. 查看设备日志
  3. 所有日志

您那里可能有很多日志,并且为了以后更容易找到您导入的日志,您可以继续删除所有日志...除非它们对您来说意味着金钱。或者除非您知道崩溃发生的确切时间点 - 无论如何它都应该写入文件中......我很懒所以我只是删除了所有旧日志(这实际上需要一段时间)。

  1. 只需将文件拖放到该列表中即可。它对我有用。

【讨论】:

  • 我遇到了同样的问题,但这并不能解决我的问题 - 我拖放到窗口中的日志会出现,但没有符号化。
  • 诀窍是您必须连接设备并从列表中选择设备。我认为没有设备是不可能的。
  • 为了让您的崩溃文件可以拖到该列表中,它应该具有扩展名.crash
  • 对我来说缺少的步骤是一旦文件被删除,我需要鼠标右键单击文件并重新符号化日志
  • 不要忘记在 Organizer 中为该存档“下载 dSYM”。
【解决方案4】:

对我来说,.crash 文件就足够了。没有 .dSYM 文件和 .app 文件。

我在构建存档的 Mac 上运行了这两个命令,并且它工作正常:

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

/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash  /yourPath/crash1.crash > /yourPath/crash1_symbolicated.crash

【讨论】:

  • 哇。如果没有 .dsym 文件,我不知道它是如何工作的,但它可以工作!
  • @rustyMagnet 它的工作方式是使用计算机上存档构建中的 dsym。
  • 是的,这仅适用于您使用 Xcode 归档的构建,而不适用于您可能为临时运行生成的任何其他构建,然后您希望为其符号化崩溃日志。
【解决方案5】:

使用 Xcode 有一种更简单的方法(无需使用命令行工具,一次只查找一个地址)

  1. 获取任何 .xcarchive 文件。如果你以前有一个,你可以使用它。如果您没有,请通过从 Xcode 运行 Product > Archive 创建一个。

  2. 右键单击 .xcarchive 文件并选择“显示包内容”

  3. 将 dsym 文件(崩溃的应用版本)复制到 dSYMs 文件夹

  4. 将 .app 文件(崩溃的应用版本)复制到 Products > Applications 文件夹

  5. 编辑 Info.plist 并编辑 ApplicationProperties 字典下的 CFBundleShortVersionString 和 CFBundleVersion。这将帮助您稍后识别存档

  6. 双击 .xcarchive 将其导入 Xcode。它应该打开管理器。

  7. 返回崩溃日志(在 Xcode 的设备窗口中)

  8. 将 .crash 文件拖到那里(如果还没有的话)

  9. 现在应该对整个崩溃日志进行符号化。如果没有,则右键单击并选择“重新符号化崩溃日志”

【讨论】:

  • 您的回答正确而简单。无需使用终端应用程序。 .xcarchive 文件夹的重新创建非常重要,因为在某些持续集成系统中没有 .xcarchive 文件,而不是 .app.dSYM 文件夹的压缩包。巧合的是,我昨天做的和你说的一模一样。
  • 完整的输出应该是什么样子?
  • 这部分象征着我的崩溃日志,尽管我确实跳过了第 3-5 步,因为我的 xcarchive 是针对崩溃的应用程序的版本。
  • 它当然只会象征你自己的代码——而不是你可能使用过的外部库代码。
  • 如果拖动不起作用怎么办?该文件确实具有 .crash 扩展名,但窗口拒绝它(它会在它向后移动的位置执行动画)。不管我把它拖到哪里,或者我是否选择了所有日志。
【解决方案6】:

Xcode 11.2.1,2019 年 12 月

Apple 为您提供 .txt 格式的崩溃日志,这是非符号化的

**

连接设备

**

  • 下载“.txt”文件,将扩展名改为“.crash”
    • 在 Xcode 的窗口选项卡中打开设备和模拟器
    • 选择设备并选择设备日志
    • 将 .crash 文件拖放到设备日志窗口

我们将能够在那边看到符号化的崩溃日志

有关符号化Crash logs 的更多详细信息,请参阅链接

【讨论】:

  • 哇。将文件扩展名从 .txt 更改为 .crash 做到了。他们给了我一个 .txt 文件。谢啦。不敢相信你的回答这么低。
【解决方案7】:

按照 Xcode 10 中的这些步骤来符号化来自同一台机器上构建的应用程序的崩溃日志:

  1. Organizer 中,找到应用所基于的存档。
  2. 点击下载调试符号按钮。您的“下载”文件夹中不会出现任何内容,但没关系。
  3. 将构建机器连接到 iOS 设备。
  4. 设备和模拟器中选择设备。
  5. 点击查看设备日志按钮。
  6. 将崩溃文件拖放到左侧面板。文件必须以 .crash 扩展名结尾,否则拖动失败。
  7. 切换到所有日志标签。
  8. 选择添加的崩溃文件。
  9. 文件应自动符号化,否则使用右键单击上下文菜单项重新符号化日志

【讨论】:

  • 起初我并不认为这会在其他帖子中添加任何内容,但前两个步骤,特别是“下载调试符号”,似乎是我所缺少的。谢谢。
【解决方案8】:

如果您将 .dSYM 和 .crash 文件放在同一个子文件夹中,您可以采取以下步骤:

  1. 查看 .crash 文件中的回溯,注意第二列中二进制图像的名称和第三列中的地址(例如,下面示例中的 0x00000001000effdc)。
  2. 在回溯下方,在“二进制图像”部分,记下二进制图像(例如 TheElements)的图像名称、架构(例如 arm64)和加载地址(下例中的 0x1000e4000)。
  3. 执行以下操作:

$ atos -arch arm64 -o TheElements.app.dSYM/Contents/Resources/DWARF/TheElements -l 0x1000e4000 0x00000001000effdc -[AtomicElementViewController myTransitionDidStop:finished:context:]

权威来源:https://developer.apple.com/library/content/technotes/tn2151/_index.html#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATE_WITH_ATOS

【讨论】:

  • 这对我有用。请注意,倒数第二个数字(上例中为 0x1000e4000)位于二进制图像部分的第一列或堆栈跟踪的第四列。此外,不必将 .dSYM 和 .crash 文件放在同一个子文件夹中。
【解决方案9】:

确保您的 Xcode 应用程序名称不包含任何空格。这就是它对我不起作用的原因。所以/Applications/Xcode.app 有效,而/Applications/Xcode 6.1.1.app 无效。

【讨论】:

  • 你试过了吗?如果没有,请尝试看看您的评论是否有意义。
  • 这和我说的不是同一个问题。 Xcode 可以在安装后重命名,但在第一次使用之前。但是,符号化脚本无法处理应用程序名称中的空格并且会失败。
  • @ChuckKrutsinger 你真的试过了吗?因为转义的空格将允许您运行脚本,但脚本本身会失败。该脚本可能不会使用转义空格调用其他脚本。
  • @ChuckKrutsinger 这很好,但如果希望 Xcode 自动符号化崩溃日志,你最终需要我的回答。
  • 我想重申一下 bouke 是正确的,如果 Xcode 应用程序的路径中有空格,Xcode 用来重新符号化崩溃日志的脚本将不起作用。与手动重新符号化无关。
【解决方案10】:

来自 Apple 的文档:

使用 Xcode 符号化崩溃报告 Xcode 将自动尝试符号化它遇到的所有崩溃报告。符号化所需要做的就是将崩溃报告添加到 Xcode Organizer。

  • 将 iOS 设备连接到您的 Mac
  • 从“窗口”菜单中选择“设备”
  • 在左列的“设备”部分下,选择一个设备
  • 点击右侧面板“设备信息”部分下的“查看设备日志”按钮
  • 将崩溃报告拖到显示面板的左列
  • Xcode 会自动符号化崩溃报告并显示结果 为了表示崩溃报告,Xcode 需要能够定位以下内容:

    1. 崩溃的应用程序的二进制和 dSYM 文件。

    2. 应用程序链接到的所有自定义框架的二进制文件和 dSYM 文件。对于使用应用程序从源代码构建的框架,它们的 dSYM 文件将与应用程序的 dSYM 文件一起复制到存档中。对于由第三方构建的框架,您需要向作者索取 dSYM 文件。

    3. 该应用程序崩溃时运行的操作系统的符号。这些符号包含特定操作系统版本(例如 iOS 9.3.3)中包含的框架的调试信息。操作系统符号是特定于体系结构的 - 用于 64 位设备的 iOS 版本将不包含 armv7 符号。 Xcode 会自动从您连接到 Mac 的每台设备上复制操作系统符号。

如果缺少其中任何一个,Xcode 可能无法符号化崩溃报告,或者可能只能部分符号化崩溃报告。

【讨论】:

    【解决方案11】:

    符号化崩溃日志的最简单过程:

    1. 在 IPA 构建过程中保留来自组织者的 xcarchive 文件以供将来使用。
    2. 当崩溃发生时,从受影响的设备收集崩溃日志。扩展名应该是 .crash。如果崩溃日志是 .ips 格式,只需将其重命名为 .crash。
    3. 双击存储路径中的 xcarchive 以使其出现在管理器中(如果尚未出现)。
    4. 在xcode窗口中打开->设备和模拟器->查看设备日志->所有日志->拖放.crash文件。

    等待 5 秒。砰!堆栈跟踪中的应用程序调用将被符号化! 不过,您可能仍然会看到很多符号!这些是内部库和框架调用。

    这是最简单的,经过尝试和测试!

    【讨论】:

      【解决方案12】:

      我一直在努力通过 atos 符号化崩溃报告,但我不情愿,因为这个过程看起来很麻烦,但我在 Xcode-> 窗口-> Organizer->Crashes(在左侧菜单中)Xcode 中找到了崩溃报告会自动下载崩溃日志并自动进行符号化,从那里你可以很容易地找到崩溃的原因。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2015-12-24
        • 2017-08-04
        • 1970-01-01
        • 1970-01-01
        • 2011-07-24
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多