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

Question

我正在寻找尝试象征我的 iPhone 应用程序的崩溃报告。

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

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

现在怎么办？

我试过调用：

symbolicatecrash crashreport.crash myApp.app.dSYM

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

难道我做错了什么？

Answer 1

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

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

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 ，将其解压缩，然后我们可以获得一个包含应用程序的有效负载文件夹。在这种情况下，我们不需要 .dSYM 文件。

笔记

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

更多详情见此帖

Answer 2

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

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

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

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

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

mdfind 'com_apple_xcode_dsym_uuids = *'

分别

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

第一个 Spotlight 调用为您提供所有索引的 dSYM 包，第二个为您.dSYM提供具有特定 UUID 的包。如果聚光灯没有找到您的.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.

Answer 3

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

Answer 4

我使用以下步骤成功地做到了这一点。

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

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

或者

“内容->开发者->平台->iPhoneOS.platform->开发者->库->PrivateFrameworks-> DTDeviceKitBase.framework- >版本->A->资源”

或者

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

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

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

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

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

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

Answer 5

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

针对 XCODE 9 更新

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

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

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

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

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

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

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

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

Answer 6

在运行 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
}

那里添加的论点可能会对您有所帮助。

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

mdfind 'com_apple_xcode_dsym_uuids = *'

查找目录中的 dsym。

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

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

Answer 7

我在我的应用程序中使用 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. 然后我在该块光标处复制/粘贴我的符号代码并按 Enter。你会看到类似的东西：

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

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

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

享受！

Answer 8

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

脚步

1.Xcode>窗口>设备。

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

3.选择查看设备日志。

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

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

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

Answer 9

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

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

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

Answer 10

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

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

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

Answer 11

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

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

Answer 12

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

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

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

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

Answer 13

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

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

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

Answer 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\"";

Answer 15

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

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

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

Answer 16

对我有用的组合是：

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

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

Answer 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);

matchUUID 函数中的第 265 行附近

265             return 1;

Answer 18

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

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

快乐的编码，
里亚兹

Answer 19

我更喜欢一个能代表我所有的崩溃日志的脚本。

前提条件

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

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

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

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

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. 在运行脚本之前，您不需要从旧崩溃中清除目录。它会自动清洁。祝你好运！

Answer 20

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

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

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

Answer 21

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

Answer 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"绕过坏字符。

Answer 23

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

xcrun atos

警告：/usr/bin/atos 正在移动，将从未来的 OS X 版本中删除。它现在可以在 Xcode 开发人员工具中通过以下方式调用：xcrun atos

Answer 24

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

Answer 25

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

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

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

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

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

...