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

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

然后，我使用我的 .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

我不得不对 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;

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

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

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

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

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

分析Apple崩溃报告的步骤：

1. 将推送到应用商店的发布.app文件、发布时创建的 .dSYM 文件以及从 APPLE 收到的崩溃报告复制到文件夹中。

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

3. 跑。根据报告，内存位置应该是应用程序崩溃的位置。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 重命名扩展名 .ipa，提取它，然后我们就可以得到一个包含应用程序的有效负载文件夹。在这种情况下，我们不需要 .dSYM 文件。

注意

仅当应用程序二进制文件未剥离符号时，这才有效。默认情况下，发布版本会剥离符号。我们可以在项目构建设置“复制过程中剥离调试符号”中将其更改为 NO。

更多细节，请参阅此帖子

这是我在 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\"";

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

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

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

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

• 打开管理器，
• 单击“库”|”左列中的设备日志
• 点击屏幕底部的“导入”按钮...

瞧。日志文件将自动导入并符号化。前提是您先使用 Xcode -> Product -> Archive 存档构建。

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

如果回溯需要，我用 atos 来象征它们的方式如下：

1. 在 Xcode （4.2） 中，转到管理器，右键单击 生成 .ipa 文件。

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

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

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

5. 然后，我将我的符号代码复制/粘贴到该块光标上，然后按 进入。您会看到类似以下内容：

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

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

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

享受！

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

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

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

在 Xcode 4.2.1 中，打开管理器，然后前往“资源库/设备日志”，将 .crash 文件拖到崩溃日志列表中。几秒钟后，它将为您象征化。

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

对我有用的组合是：

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

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

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

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

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

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

每个二进制文件都由一个 UUID 引用，该 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 with 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.dSYMsymbolicatecrash~/Desktop

如果找到您的包，则应该有一行，如下所示：symbolicatecrash.dSYMsymbolicate.log

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

为了查找您的包，将调用如下所示的聚光灯搜索：.appsymbolicatecrash

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

如果找到您的包，则应包含以下摘录：symbolicatecrash.appsymbolicate.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

我有点脾气暴躁，因为这里似乎没有什么“只是工作”，所以我做了一些调查，结果是：

设置：接收报告的 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 ~第 202 行。它似乎没有得到正确的时间戳，所以文件最终以 Xcode 无法识别的名称“crash”结束（它想要点崩溃的东西）：

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

其次，在 iOS 端的 QuincyKit BWCrashReportTextFormatter.m ~第 176 行，更改为绕过错误字符。@"[TODO]"@"TODO"

我使用以下步骤成功地完成了此操作。

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

步骤2：打开Finder并转到应用程序，您将在其中找到Xcode应用程序，右键单击此应用程序，然后单击“显示包内容”，然后按照此简单路径进行操作。 “Contents->Developer->Platforms->iPhoneOS.platform->Developer->Library->PrivateFrameworks->DTDeviceKit.framework->Versions->A->Resources”

或

“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 个命令

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

2. export DEVELOPER_DIR=“/Applications/Xcode.app/Contents/Developer”并按 Enter 键

3. ./symbolicatecrash -A -v MYApp_2013-07-18.crash MyApp.app.dSYM 并按 Enter 键 现在完成。.（注意：6.4 或更高版本的版本没有 -A 选项 - 只需将其省略即可）。

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

xcrun atos

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

尽管我已经开发应用程序几年了，但这是我第一次调试二进制文件，我感觉自己像一个完整的菜鸟，弄清楚所有文件的位置，即*.app *.dSYM和崩溃日志在哪里？为了弄清楚，我不得不阅读多篇文章。图片胜过千言万语，我希望这篇文章将来能帮助到其他人。

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

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

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

步骤

1.Xcode>Window>Devices。

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

3.选择查看设备日志。

4.在“所有日志”部分下，您可以直接拖拽 report.crash

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

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

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

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

针对 XCODE 9 进行了更新

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

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

3. 单击左侧的设备，右侧的 VIEW DEVICE LOGS

4. 等。可能需要一分钟才能显示。也许这样做会加快速度。Command-ADelete

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

6. 将崩溃报告拖动到左侧的该区域

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

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

这很简单，在搜索了很多之后，我找到了明确的步骤来符号化整个崩溃日志文件。

• 将 .app、crash_report 和 DSYM 文件复制到文件夹中。
• 将设备与 Xcode 连接
• 然后进入窗口 -> 选择设备 -> 查看设备日志
• 然后选择此设备，删除所有日志。
• 将崩溃拖放到设备日志部分。它会自动象征崩溃。只需右键单击报告并将其导出即可。

快乐编码，
里亚兹

我更喜欢一个可以象征我所有崩溃日志的脚本。

前提 条件

创建一个文件夹并放在那里 4 件事：

1. symbolicatecrashperl 脚本 - 有许多 SO 答案可以告诉它的位置

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

3. 所有软件包 - （从 Xcode Organizer. ，您可以复制目录中的所有软件包，或者您想要符号化的单个 xccrashpoint）xccrashpointShow in Finder

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

   #!/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 个目录。

1. allCrashes- 所有崩溃都会在那里。xccrashpoint

2. symboledCrashes- 同样的崩溃，但现在所有的符号。

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

我们使用 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）），可以手动将其配置为作为项目构建过程的一部分运行。有关配置说明，请参阅下面的 upload-symbols 部分。

...

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

我建议使用 Symbolicator 工具 https://github.com/agentsim/Symbolicator

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

对于那些在 2022 年寻找有效解决方案的人

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

• 将苹果提供的崩溃日志格式转换为.txt.crash
• Xcode > Window > Devices and simulators
• 必须选择已连接且正在运行的 ios 设备。（不是模拟器或离线设备）
• 选择部分，拖放文件All Logs.crash

---

请注意，其他解决方案已被弃用，其用法显示：symbolicatecrash

⚠️ symbolicatecrash 已弃用;它将在 Xcode ⚠️ 的未来版本中删除