符号化 iPhone 应用程序崩溃报告

Posted 2023-02-23

【中文标题】符号化 iPhone 应用程序崩溃报告

【英文标题】：Symbolicating iPhone App Crash Reports

【发布时间】：2009-09-22 15:44:21

【问题描述】：

我正在尝试用符号化我的 iPhone 应用程序的崩溃报告。

我从 iTunes Connect 检索了崩溃报告。我有我提交到 App Store 的应用程序二进制文件，并且我有作为构建的一部分生成的 dSYM 文件。

我将所有这些文件放在一个由 Spotlight 索引的目录中。

现在呢？

我尝试过调用：

symbolicatecrash crashreport.crash myApp.app.dSYM

它只是输出与崩溃报告中相同的文本，而不是符号化的。

我做错了吗？

【问题讨论】：

你也可以在iPhone SDK : Where is symbolicatecrash.sh located?看到我的回答。我列出了在哪里可以找到symbolicatecrash 命令、如何使用它以及如何找到进行符号化所需的 dSYM 文件。

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

我创建了一个可能有帮助的脚本：github.com/amleszk/scripts/blob/master/…

如果有人想知道在哪里可以获得 *.app、*.dSYM 和崩溃日志，请查看下面的答案。

你可以参考这个：medium.com/@Mrugraj/crash-re-symbolication-5c28d3a3a883

【参考方案1】：

分析苹果崩溃报告的步骤：

将推送到应用商店的发布 .app 文件、发布时创建的 .dSYM 文件和从 APPLE 接收的崩溃报告复制到 FOLDER。

打开终端应用程序并转到上面创建的文件夹（使用cd 命令）

运行atos -arch armv7 -o APPNAME.app/APPNAME MEMORY_LOCATION_OF_CRASH。根据报告，内存位置应该是应用崩溃的位置。

例如：atos -arch armv7 -o 'APPNAME.app'/'APPNAME' 0x0003b508

这将向您显示导致崩溃的确切行和方法名称。

例如：[classname functionName:]; -510

象征国际音标

如果我们使用 IPA 进行符号化 - 只需将扩展名 .ipa 重命名为 .zip ，提取它然后我们可以获得一个包含应用程序的有效负载文件夹。在这种情况下，我们不需要 .dSYM 文件。

注意

这只有在应用程序二进制文件没有剥离符号时才有效。默认情况下，发布版本会剥离符号。我们可以在项目构建设置“Strip Debug Symbols during Copy”中将其更改为 NO。

更多详情请看post

【讨论】：

只是对@NaveenShan 答案的提示，一个真实的例子会这样做atos -o myApp.app/Contents/MacOS/myApp 0x0000000100001f2c，你会得到-[HUDWindow sizedHUDBackground] (in myApp) + 1197

您使用哪个地址？日志在每个函数之后有两列地址，第二列有一个 + 和某种偏移量。比如 0x332da010 0x332d9000 + 4112。

@OscarGoldman 第二个地址 eg:- In 0x332da010 0x332d9000 + 4112. use 0x332d9000.

另外，如果不使用地址，它允许您通过一个一个提交来分析多个位置。

这个答案存在多个问题： 1. 这只有在应用程序二进制文件没有剥离符号时才有效。并且默认情况下发布版本确实将它们剥离。 2. 即使符号可用，它也永远不会显示行号。只有用 dSYM 进行符号化才能提供。 3. 您不能简单地使用堆栈跟踪中显示的内存地址，该地址必须根据加载应用程序的起始内存地址进行规范化。更多细节见这个答案：***.com/questions/13574933/…

【参考方案2】：

在这里阅读所有这些答案以符号化崩溃日志（并最终成功）后，我认为这里缺少一些非常重要的点，以便确定为什么调用 symbolicatecrash 不会产生符号化输出。

在符号化崩溃日志时，必须将 3 个资产组合在一起：

崩溃日志文件本身（即example.crash），从 XCode 的管理器导出或从 iTunes Connect 接收。 .app 包（即example.app）本身包含属于崩溃日志的应用程序二进制文件。如果您有一个.ipa 包（即example.ipa），那么您可以通过解压缩.ipa 包（即unzip example.ipa）来提取.app 包。之后，.app 包驻留在解压缩的 Payload/ 文件夹中。 包含调试符号的.dSYM 包（即example.app.dSYM）

在开始符号化之前，您应该检查所有这些工件是否匹配，这意味着崩溃日志属于您拥有的二进制文件，并且调试符号是在构建该二进制文件期间生成的。

每个二进制文件都由一个 UUID 引用，可以在崩溃日志文件中看到：

...
Binary Images:
0xe1000 -    0x1f0fff +example armv7  <aa5e633efda8346cab92b01320043dc3> /var/mobile/Applications/9FB5D11F-42C0-42CA-A336-4B99FF97708F/example.app/example
0x2febf000 - 0x2fedffff  dyld armv7s  <4047d926f58e36b98da92ab7a93a8aaf> /usr/lib/dyld
...

在此提取中，崩溃日志属于名为 example.app/example 且 UUID aa5e633efda8346cab92b01320043dc3 的应用二进制映像。

您可以使用 dwarfdump 检查您拥有的二进制包的 UUID：

dwarfdump --uuid example.app/example
UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app/example

之后，您应该检查您拥有的调试符号是否也属于该二进制文件：

dwarfdump --uuid example.app.dSYM
UUID: AA5E633E-FDA8-346C-AB92-B01320043DC3 (armv7) example.app.dSYM/Contents/Resources/DWARF/example

在此示例中，所有资产都组合在一起，您应该能够符号化您的堆栈跟踪。

继续执行symbolicatecrash 脚本：

在 Xcode 8.3 中，您应该能够通过

调用脚本

/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash -v example.crash 2> symbolicate.log

如果不存在，您可以在 Xcode.app 目录中运行 find . -name symbolicatecrash 来找到它。

如您所见，没有给出更多参数。因此脚本必须通过运行聚光灯搜索来找到您的应用程序二进制文件和调试符号。它使用名为com_apple_xcode_dsym_uuids 的特定索引搜索调试符号。您可以自己进行此搜索：

mdfind 'com_apple_xcode_dsym_uuids = *'

分别

mdfind "com_apple_xcode_dsym_uuids == AA5E633E-FDA8-346C-AB92-B01320043DC3"

第一个 Spotlight 调用为您提供所有索引的 dSYM 包，第二个为您提供具有特定 UUID 的 .dSYM 包。如果 Spotlight 找不到您的 .dSYM 包，那么 symbolicatecrash 也不会。如果你做所有这些事情，例如在~/Desktop 聚光灯的子文件夹中应该能够找到所有内容。

如果symbolicatecrash 找到你的.dSYM 包，symbolicate.log 中应该有如下一行：

@dsym_paths = ( <SOME_PATH>/example.app.dSYM/Contents/Resources/DWARF/example )

为了找到您的.app 包，symbolicatecrash 调用如下的聚光灯搜索：

mdfind "kMDItemContentType == com.apple.application-bundle && (kMDItemAlternateNames == 'example.app' || kMDItemDisplayName == 'example' || kMDItemDisplayName == 'example.app')"

如果symbolicatecrash 找到你的.app 包，symbolicate.log 中应该有以下摘录：

Number of symbols in <SOME_PATH>/example.app/example: 2209 + 19675 = 21884
Found executable <SOME_PATH>/example.app/example
-- MATCH

如果symbolicatecrash 找到了所有这些资源，它应该会打印出崩溃日志的符号版本。

如果没有，您可以直接传入您的 dSYM 和 .app 文件。

symbolicatecrash -v --dsym <SOME_PATH>/<App_URI>.app.dSYM/<APP_NAME>.app.dsym <CRASHFILE> <SOME_OTHER_PATH>/<APP_NAME>.app/<APP_NAME> > symbolicate.log

注意：符号化的回溯将输出到终端，而不是symbolicate.log。

【讨论】：

我可以找到所有文件但是我得到了这个，并且没有符号输出No crash report version in testlog.crash at /usr/bin/symbolicatecrash line 921.

这真的很有帮助！在我的情况下，.app 文件的名称与可执行文件的名称不同（我不知道为什么，但它是由 Xcode 以这种方式构建的）。在 XCode 存档中重命名 .app 文件后，符号化确实起作用了。

这是一个很好的解释，应该是 IMO 的最佳答案，谢谢。请注意，如果脚本像这样抱怨它，您可能必须设置 DEVELOPER_DIR 环境变量：export DEVELOPER_DIR=`xcode-select --print-path` 。我将此行添加到我的~/.bash_profile。见***.com/q/11682789/350761

请注意，对于 Xcode 5，这已移至：/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/Current/Resources /symbolicatecrash

象征性崩溃也有几个有用的选项。 <SYMBOL_PATH> Additional search paths in which to search for symbol rich binaries-o | --output <OUTPUT_FILE> The symbolicated log will be written to OUTPUT_FILE. Defaults to "-" (i.e. stdout) if not specified-d | --dsym <DSYM_BUNDLE> Adds additional dSYM that will be consulted if and when a binary's UUID matches (may be specified more than once)

【参考方案3】：

使用最新版本的 Xcode (3.2.2)，您可以将任何崩溃报告拖放到 Xcode Organizer 的设备日志部分，它们会自动为您符号化。我认为如果您使用 Build & Archive（也是 Xcode 3.2.2 的一部分）构建该版本的应用程序，这将最有效

【讨论】：

这根本不适用于全新安装的 Xcode4。似乎是一个新的错误:(

我不确定这是否能解决你遇到的同样问题，但有人修补了符号脚本github.com/nskboy/symbolicatecrash-fixYMMV :)

本技巧适用于 Xcode 4.2。将崩溃日志放在 Organizer 的设备日志中。重新启动 Organizer 将获得象征性的崩溃日志！！！谢谢。

当我从另一台计算机导入存档文件以获取崩溃日志时，这对我不起作用。 :( 出于这个原因，我不得不手动对文件进行符号化。您可以在此处找到有关如何进行符号化的步骤：iPhone SDK : Where is symbolicatecrash.sh located?

不要为我使用从 iTunes Connect 下载的崩溃报告。

【参考方案4】：

我成功地做到了，使用以下步骤。

第1步： 在桌面创建一个文件夹，我将其命名为“CrashReport”并放入三个文件（“MYApp.app”、“MyApp.app.dSYM”、“MYApp_2013-07 -18.crash")。

第 2 步： 打开 Finder 并转到 Applications，您将在其中找到 Xcode 应用程序，右键单击它并单击“显示包内容”，然后按照这个简单的路径。 “内容->开发者->平台->iPhoneOS.platform->开发者->库->PrivateFrameworks->DTDeviceKit.framework->版本->A->资源”

或

“Contents->Developer->Platforms->iPhoneOS.platform->Developer->Library->PrivateFrameworks->DTDeviceKitBase.framework->Versions->A->Resources”

或

对于 Xcode 6 及更高版本，路径为 Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources

在您找到“symbolicatecrash”文件的地方，将其复制并粘贴到“CrashReport”文件夹中。

第 3 步：启动终端，运行这 3 个命令

cd /Users/mac38/Desktop/CrashReport 并按 Enter 按钮

导出 DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer" 并按 Enter 键

./symbolicatecrash -A -v MYApp_2013-07-18.crash MyApp.app.dSYM 并按 Enter Now it Done.. （注意：6.4 或更高版本没有 -A 选项 - 只需保留它出）。

【讨论】：

对于 DTServiceKit 查看 Applications/Xcode.app/Contents/SharedFrameworks

谢谢...截至 2015 年 4 月 9 日，这对我来说完美无缺。一件事是我得到了 Unknown option: A 的符号崩溃，但这个过程仍然运行

我希望我能给这个答案一千分。关于这个主题有很多方法......但这是在最低级别工作的一个，所以它总是有效的。打完所有的台阶很痛苦，但是当其他一切都失败时，这可以完成工作。

【参考方案5】：

使用 XCode 自动符号化崩溃报告的步骤：

针对 XCODE 9 更新

将任何 ios 设备连接到您的 Mac（是的物理设备，是的，我知道这很愚蠢）

从“窗口”菜单中选择“设备”

单击左侧的设备并在右侧查看设备日志

等等。显示可能需要一分钟。也许先做Command-A 然后Delete 会加快速度。

关键的未记录步骤：将您从 iTunesConnect 获得的崩溃报告从 .txt 扩展名重命名为 .crash 扩展名

将崩溃报告拖到左侧的那个区域

然后Xcode会符号化崩溃报告并显示结果。

来源：https://developer.apple.com/library/ios/technotes/tn2151/_index.html

【讨论】：

这是苹果官方程序。应该是答案。

谢谢，我正在添加图片。还包括超级未记录的步骤。我想制作一个红色文本的 git 并将其拼接在那里，这样它才能真正脱颖而出。然后我就不再想那个了。

谢谢！其他答案实际上都没有说您使用的设备不需要是发生崩溃的设备（甚至设备类型）。

快速注释，因为对我来说它不会重新符号化。我还必须打开管理器，单击存档中的构建，单击下载调试符号。然后我可以在设备日志视图中重新符号化。这是针对被拒绝审核后从 Apple 下载的崩溃日志。

【参考方案6】：

我在我的应用程序中使用 Airbrake，它在远程错误记录方面做得相当好。

如果回溯需要，我会使用 atos 来表示它们：

在 Xcode (4.2) 中转到管理器，右键单击来自的存档 生成 .ipa 文件。

在终端中，cd 进入 xcarchive 例如MyCoolApp 10-27-11 1.30 PM.xcarchive

输入以下atos -arch armv7 -o 'MyCoolApp.app'/'MyCoolApp' （不要忘记单引号）

我没有在该调用中包含我的符号。你得到的是一个空行上的块光标。

然后我在该块光标处复制/粘贴我的符号代码并按 进入。您会看到如下内容：

-[MyCoolVC dealloc] (in MyCoolApp) (MyCoolVC.m:34)

您返回到块光标，您可以粘贴其他符号。

能够在不重新输入第一个位的情况下通过回溯一个项目是一个很好的节省时间的方法。

享受吧！

【参考方案7】：

在运行 symbolicate crash 之前，我还将 dsym、app bundle 和崩溃日志放在同一个目录中

然后我使用我的 .profile 中定义的这个函数来简化运行 symbolicatecrash：

function desym

    /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash -A -v $1 | more

在此处添加的参数可能会对您有所帮助。

您可以通过运行以下命令检查以确保 Spotlight“看到”您的dysm文件：

mdfind 'com_apple_xcode_dsym_uuids = *'

在您的目录中查找您的 dsym。

注意：从最新的 Xcode 开始，不再有 Developer 目录。您可以在此处找到此实用程序：

/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Vers‌​ions/A/Resources/symbolicatecrash

【讨论】：

我查看了mdfind的输出，dSYM文件肯定可以被spotlight看到。但是， symbolicatecrash 脚本仍然不会输出与崩溃报告本身不同的任何内容。即使使用您提供的参数。

如果脚本找不到 dsym，它应该在开头产生一些警告文本 - 你能找到它并看看它说什么吗？

另外，尝试添加“.”在命令之后，所以它将是“symbolicatecrash -A -v MyApp.crashlog ”。 .如果它还没有这样做，这会迫使它在当前目录中查找。

意思是“无法执行”/usr/bin/xcode-select”：/Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Plug-ins/ 中没有这样的文件或目录iPhoneRemoteDevice.xcodeplugin/Contents/Resources/symbolicatecrash 第 49 行。”

哎呀，显然还有另一个问题***.com/questions/1859852/…

【参考方案8】：

只是 xcode 6.1.1 的一个简单且更新的答案。

步骤

1.Xcode>窗口>设备。

2.从设备部分下的设备列表中选择一个设备。

3.选择查看设备日志。

4.在All Logs部分下可以直接拖拽report.crash

5.Xcode 会自动为你符号化崩溃报告。

6.您可以通过将其日期/时间与崩溃报告中提到的日期/时间相匹配来找到符号化崩溃报告。

【讨论】：

我从 Apple 解决方案中心下载的崩溃报告通常具有 .txt 扩展名。请记住将它们重命名为 .crash，否则设备日志可能会拒绝添加它们。适用于我当前的 XCode 6.3.1

这是苹果官方程序。应该是答案。苹果链接：Technical Note TN2151: Understanding and Analyzing iOS Application Crash Reports

如果崩溃来自 Apple/iTunesConnect，我们该怎么做？所以换句话说，我们实际上并不知道或不知道发生崩溃的设备？

【参考方案9】：

尽管我已经开发应用程序几年了，但这是我第一次调试二进制文件，我觉得自己像一个完整的 NOOB，弄清楚所有文件在哪里，即 *.app *.dSYM 和崩溃日志在哪里?我必须阅读多个帖子才能弄清楚。图片值一千字，我希望这篇文章对以后的其他人有所帮助。

1- 首先转到 iTunesconnect 并下载您的崩溃日志。 注意：在大多数情况下，您可能会收到“提交的报告太少，无法显示报告”之类的信息。基本上没有足够的用户向 Apple 提交崩溃日志报告，在这种情况下，您此时无能为力。

2- 现在，如果您在将二进制文件提交给 Apple 后没有更改代码，则为该项目启动 Xcode 并再次执行 Product --> Archive。否则，只需找到您最新提交的二进制文件并右键单击它。

【参考方案10】：

在 Xcode 4.2.1 中，打开 Organizer，然后转到 Library/Device Logs 并将您的 .crash 文件拖到崩溃日志列表中。几秒钟后，它会为你象征性地出现。

请注意，您必须使用与原始构建存档相同的 Xcode 实例（即，您构建的存档必须存在于 Organizer 中）。

【参考方案11】：

使用 Xcode 4，任务更加简单：

打开组织者， 点击库|左栏中的设备日志 点击屏幕底部的“导入”按钮...

然后瞧。日志文件会自动为您导入和符号化。前提是您首先使用 Xcode -> Product -> Archive 归档了构建。

【讨论】：

很奇怪，导入没有效果。将 .app、.dSYM 和 .crash 然后在 .crash 文件上运行 symbolicatecrash（没有任何额外的参数）仍然有效（XCode 4）

【参考方案12】：

神奇的 Xcode Organizer 在符号化我的应用程序方面并没有那么神奇。我从 Apple 提交的应用程序提交失败后收到的崩溃报告根本没有任何符号。

我尝试使用命令行，将崩溃报告与 .app 文件（我提交给商店）和 .dSYM 文件放在同一文件夹中：

$ symbolicatecrash "My App_date_blahblah-iPhone.crash" "My App.app"

这只是为我的应用程序提供了符号，而不是核心基础代码，但它比 Organizer 给我的数字转储要好，足以让我找到并修复我的应用程序的崩溃。如果有人知道如何扩展它以获得 Foundation 符号，将不胜感激。

【讨论】：

对于核心 Foundation dSYM，一个（可能是中国人）已经将 dSYM 上传到他共享的 google 驱动器上，只需下载并放入“支持的设备”文件夹即可解决。 github.com/Zuikyo/iOS-System-Symbols

【参考方案13】：

就我而言，我将崩溃报告直接从 Mail 拖到 Organizer。出于某种原因，这阻止了崩溃报告的符号化（我很想知道为什么）。

首先将崩溃报告复制到桌面，然后将它们从那里拖到管理器中，以便正确符号化它们。

非常具体的情况，我知道。但我想我会分享以防万一。

【讨论】：

我想这可能与聚光灯有关。组织者保存您的日志的位置是否有可能没有被聚光灯索引？

【参考方案14】：

这是我遇到的另一个关于 symbolicatecrash 的问题 - 它不适用于捆绑包中有空格的应用程序（即“测试 App.app”）。请注意，我认为您在提交时不能在其名称中包含空格，因此无论如何您都应该删除这些空格，但如果您已经有需要分析的崩溃，请像这样修补 symbolicatecrash (4.3 GM)：

240c240
<         my $cmd = "mdfind \"kMDItemContentType == com.apple.application-bundle && kMDItemFSName == $exec_name.app\"";
---
>         my $cmd = "mdfind \"kMDItemContentType == com.apple.application-bundle && kMDItemFSName == '$exec_name.app'\"";
251c251
<             my $cmd = "find \"$archive_path/Products\" -name $exec_name.app";
---
>             my $cmd = "find \"$archive_path/Products\" -name \"$exec_name.app\"";

【讨论】：

对于它的价值，我对此填写了一个 rdar，它已在 [redacted] 中修复

【参考方案15】：

对于那些使用 Airbrake 的人，上面有一个可靠的响应，但如果不进行调整，它对我来说是行不通的：

适用于某些内存地址，但不适用于其他地址，不知道为什么...

在桌面或任何地方创建新目录 在 Xcode 管理器中查找有问题的存档 双击以在查找器中显示 双击显示捆绑内容 将 .dSYM 文件和 .app 文件复制到新目录中 cd 进入新目录 运行此命令：atos -arch armv7 -o 'Vimeo.app'/'Vimeo' 终端将进入交互式移动 粘贴内存地址回车，会输出方法名和行号 或者，输入以下命令：atos -arch armv7 -o 'Vimeo.app'/'Vimeo' 仅获取一个地址的信息

【参考方案16】：

对我有用的组合是：

将 dSYM 文件复制到崩溃报告所在的目录中 解压缩包含应用程序的 ipa 文件（'unzip MyApp.ipa'） 将应用程序二进制文件从生成的分解负载复制到与崩溃报告和符号文件相同的文件夹中（类似于“MyApp.app/MyApp”） 从 Xcode 的管理器中导入或重新符号化崩溃报告

使用 atos 我无法使用崩溃报告中的地址和偏移量解析正确的符号信息。当我这样做时，我看到了一些更有意义的东西，而且它似乎是一个合法的堆栈跟踪。

【参考方案17】：

我不得不对 symbolicatecrash 脚本进行大量修改才能使其正常运行。

据我所知，symbolicatecrash 现在要求 .app 与 .dsym 位于同一目录中。它将使用 .dsym 来定位 .app，但不会使用 dsym 来查找符号。

在尝试这些补丁之前，您应该复制您的 symbolicatecrash，这将使其在 dsym 中显示：

getSymbolPathFor_dsymUuid 函数中的第 212 行左右

212     my @executablePath = grep  -e && ! -d  glob("$dsymdir" . "/Contents/Resources/DWARF/" . $executable);

matchesUUID 函数中的第 265 行左右

265             return 1;

【参考方案18】：

这很简单，经过大量搜索，我找到了符号化整个崩溃日志文件的明确步骤。

将 .app 、 crash_report 和 DSYM 文件复制到一个文件夹中。 用 xcode 连接设备 然后转到窗口 -> 选择设备 -> 查看设备日志 然后选择这个设备，删除所有日志。 将您的崩溃拖放到设备日志部分。它会自动象征崩溃。只需右键单击报告并将其导出。

快乐编码， 里亚兹

【讨论】：

最好的简短和甜蜜的答案，请遵循此答案中编写的每一步。 developer.apple.com/library/content/technotes/tn2151/… 点击此链接查找未符号化和完全符号化之间的区别。

【参考方案19】：

我更喜欢一个脚本，它将象征我所有的崩溃日志。

前提条件

创建一个文件夹并放 4 样东西：

symbolicatecrash perl 脚本 - 有很多 SO 答案告诉它的位置

与崩溃匹配的构建存档（来自 Xcode Organizer。简单如 Show in Finder 并复制）[我不确定这是必要的]

所有 xccrashpoint 包 - （来自 Xcode Organizer。Show in Finder，您可以复制目录中的所有包，或者您想要符号化的单个 xccrashpoint）

将该短脚本添加到目录中：

#!/bin/sh

echo "cleaning old crashes from directory"
rm -P *.crash
rm -P *.xccrashpoint
rm -r allCrashes
echo "removed!"
echo ""
echo "--- START ---"
echo ""

mkdir allCrashes
mkdir symboledCrashes
find `ls -d *.xccrashpoint` -name "*.crash" -print -exec cp  allCrashes/ \;

cd allCrashes
for crash in *.crash; do
    ../symbolicatecrash $crash > ../symboledCrashes/V$crash
done
cd ..

echo ""
echo "--- DONE ---"
echo ""

脚本

当你运行脚本时，你会得到 2 个目录。

allCrashes - 来自所有xccrashpoint 的所有崩溃都会出现。

symboledCrashes - 同样的崩溃，但现在所有符号都出现了。

在运行脚本之前，您不需要从旧崩溃中清除目录。它会自动清洁。祝你好运！

【参考方案20】：

我发现大多数提议的替代方案在最新的 XCode 中都不起作用（使用 Xcode 10 测试）。例如，我在 Xcode -> Organizer -> Device logs -view 中拖放 .crash 日志时运气不佳。

我推荐使用符号工具https://github.com/agentsim/Symbolicator

Git 克隆 Symbolicator 存储库并使用 Xcode 编译和运行 将崩溃版本的 .crash 文件（ascii 文件，在文件请求中带有堆栈跟踪）和 .xarchive 复制到同一临时文件夹中 将 .crash 文件拖放到 Dock 中的 Symbolicator 图标 在 5-30 秒内生成符号化崩溃文件，与 .crash 和 .xarchive 位于同一文件夹中

【参考方案21】：

为了象征崩溃，Spotlight 必须能够找到与您提交给 Apple 的二进制文件同时生成的 .dSYM 文件。由于它包含符号信息，如果它不可用，您将不走运。

【讨论】：

如果您阅读了这个问题，我声明我已经保存了在提交二进制文件的同时生成的原始 dSYM 文件。

【参考方案22】：

我对这里似乎没有“正常工作”的事实有点生气，所以我做了一些调查，结果是：

设置：接收报告的 QuincyKit 后端。没有设置任何符号，因为我什至无法弄清楚他们建议我做什么才能让它发挥作用。

修复：从服务器在线下载崩溃报告。它们被称为“崩溃”，默认情况下进入 ~/Downloads/ 文件夹。考虑到这一点，这个脚本将“做正确的事”，崩溃报告将进入 Xcode（管理器，设备日志）并完成符号化。

脚本：

#!/bin/bash
# Copy crash reports so that they appear in device logs in Organizer in Xcode

if [ ! -e ~/Downloads/crash ]; then 
   echo "Download a crash report and save it as $HOME/Downloads/crash before running this script."
   exit 1
fi

cd ~/Library/Logs/CrashReporter/MobileDevice/
mkdir -p actx # add crash report to xcode abbreviated
cd actx

datestr=`date "+%Y-%m-%d-%H%M%S"`

mv ~/Downloads/crash "actx-app_"$datestr"_actx.crash"

如果您确实使用 QuincyKit/PLCR，则可以通过做两件事将事情自动化到您可以在 Xcode Organizer 中拖放的位置。

首先，您必须编辑远程脚本 admin/actionapi.php ~line 202。它似乎没有正确获取时间戳，因此该文件以 Xcode 无法识别的名称 'crash' 结尾（它想要点崩溃）：

header('Content-Disposition: attachment; filename="crash'.$timestamp.'.crash"');

其次，在 iOS 端 QuincyKit BWCrashReportTextFormatter.m ~line 176，将 @"[TODO]" 更改为 @"TODO" 以绕过坏字符。

【参考方案23】：

atos 已被弃用，因此如果您运行的是 OSX 10.9 或更高版本，您可能需要运行

xcrun atos

警告：/usr/bin/atos 正在移动，将从未来的操作系统中删除 X 发布。现在可以在 Xcode 开发者工具中使用 调用方式：xcrun atos

【讨论】：

似乎 Apple 允许 DWARF 格式随着工具的每个版本而变形（这是有道理的，尤其是在 Swift 出现的情况下），因此他们将其移至工具发行版。

【参考方案24】：

我喜欢使用 Textwrangler 来查明原始应用上传二进制拒绝中的错误。 （崩溃数据将在您的 itunesConnect 帐户中找到。）使用上面 Sachin 的方法，我将 original.crash 复制到 TextWrangler，然后将我创建的 symbolicatecrash 文件复制到另一个 TextWrangler 文件。比较这两个文件可以确定差异。 symbolicatecrash 文件会有差异，指出问题所在的文件和行号。

【参考方案25】：

我们使用 Google Crashlytics 来监督崩溃日志，感觉使用起来非常及时方便。

文档链接： https://docs.fabric.io/apple/crashlytics/missing-dsyms.html#missing-dsyms

关于缺失的 dSYM Fabric 包含一个自动上传项目的 dSYM 的工具。该工具通过 /run 脚本执行，该脚本在载入过程中添加到您的运行脚本构建阶段。但是，在某些情况下，dSYM 上传会由于独特的项目配置或您在应用程序中使用 Bitcode 而失败。当上传失败时，Crashlytics 无法符号化和显示崩溃，并且您的 Fabric 仪表板上会出现“缺少 dSYM”警报。

可以按照下面概述的步骤手动上传丢失的 dSYM。

注意： 作为自动 dSYM 上传工具的替代方案，Fabric 提供了一个命令行工具 (upload-symbols))，可以手动配置它作为项目构建过程的一部分运行。有关配置说明，请参阅下面的上传符号部分。

...