象征iPhone应用崩溃报告

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

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

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

现在怎么办？

我尝试调用：

symbolicatecrash crashreport.crash myApp.app.dSYM

并且只会输出崩溃报告中相同的文本，而不是符号。

难道我做错了什么？

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

1. 副本被推到AppStore的释放.app文件，这是在释放和崩溃报告时所创建的文件.dSYM从苹果领取到一个文件夹。

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进行符号化-只需将扩展名.ipa重命名为.zip，然后将其解压缩即可得到一个包含应用程序的有效负载文件夹。在这种情况下，我们不需要.dSYM文件。

注意

仅当应用程序二进制文件中没有剥离符号时，此方法才有效。默认情况下，发布版本会删除符号。我们可以在项目构建设置“复制期间的条形调试符号”中将其更改为NO。

更多细节请看这篇文章

在阅读完所有这些答案以表示崩溃日志（并最终成功）之后，我认为这里有些遗漏非常重要，这些点对于确定为什么调用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引用，可以在崩溃日志文件中看到它：

...
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目录中运行来查找它。

如您所见，没有更多的参数了。因此，脚本必须通过运行Spotlight搜索来找到应用程序二进制文件和调试符号。它使用称为的特定索引搜索调试符号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 的软件包。如果Spotlight找不到您的.dSYM包裹，则symbolicatecrash不会。如果您做所有这些事情，例如在您的子文件夹中~/Desktop Spotlight应该能够找到所有内容。

如果symbolicatecrash找到您的.dSYM包裹，则应该在一行中显示以下内容symbolicate.log：

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

为了找到您的.app软件包，可以通过以下方式调用Spotlight搜索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。

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

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

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

步骤2：打开Finder并转到Applications（应用程序），您将在其中找到Xcode应用程序，右键单击它，然后单击“ Show Package Contents”，然后按照以下简单路径操作。“目录->开发人员->平台-> 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 Now（完成）。（注意：6.4或更高版本不具有-A选项-请将其保留）。

使用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

我在应用程序中使用了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. 返回到块光标，可以粘贴其他符号。

能够在不重新输入第一条内容的情况下通过回溯项目可以节省大量时间。

请享用！

在运行符号崩溃之前，我还将dsym，应用程序捆绑包和崩溃日志放到了同一目录中

然后，我使用.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/Versions/A/Resources/symbolicatecrash

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

脚步

1.Xcode>窗口>设备。

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

3.选择查看设备日志。

4，在所有日志部分下，您可以直接将报告拖放

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

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

即使我已经开发应用程序已有几年了，但是这是我第一次调试二进制文件，并且感觉像是一个完整的NOOB，弄清楚所有文件的位置，即* .app * .dSYM和崩溃日志在哪里？为了弄清楚，我不得不阅读多个帖子。图片值一千字，希望以后能对其他人有所帮助。

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

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

在Xcode 4.2.1中，打开Organizer，然后转到“ Library / Device Logs”，然后将.crash文件拖到崩溃日志列表中。几秒钟后，它将为您象征。

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

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

• 打开管理器，
• 点击图书馆| 设备登录在左列
• 点击屏幕底部的“ 导入 ”按钮...

和voilà。日志文件将自动为您导入并符号化。前提是您先使用Xcode->产品->存档来存档构建。

神奇的Xcode Organizer在象征我的应用方面不是那么神奇。对于苹果因失败的应用程序提交而返回的崩溃报告，我根本没有任何符号。

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

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

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

就我而言，我是将崩溃报告直接从Mail拖到管理器中。由于某些原因，这使崩溃报告无法被符号化（我很想知道为什么）。

首先将崩溃报告复制到桌面，然后将其从那里拖到管理器中，即可正确表示它们。

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

这是我与symbolicatecrash有关的另一个问题–捆绑软件中没有空格的应用程序（例如“ Test 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\"";

对于使用Airbrake的用户，上面有一个不错的响应，但如果不进行调整，它对我不起作用：

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

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

对我有用的组合是：

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

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

为了使它正常运行，我不得不对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;

这很简单，经过大量搜索后，我发现了清晰的步骤来象征整个崩溃日志文件。

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

Riyaz，快乐的编码

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

前提条件

创建一个文件夹，然后放置4件事：

1. symbolicatecrash perl脚本-有很多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. 您无需在运行脚本之前从旧崩溃中清除目录。它将自动清洁。祝好运！

我发现大多数建议的替代方法在最新的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相同的文件夹中会生成符号化的崩溃文件

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

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

设置：接收报告的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"来解决不良字符。

不推荐使用atos，因此如果您正在运行OSX 10.9或更高版本，则可能需要运行

xcrun atos

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

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

我们使用Google Crashlytics来监控崩溃日志，感觉非常及时且易于使用。

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

关于缺少dSYM的所有信息Fabric包含一个自动上载项目的dSYM的工具。该工具通过/ run脚本执行，该脚本在启动过程中已添加到您的“运行脚本构建阶段”中。但是，在某些情况下，由于独特的项目配置而导致dSYM上传失败或您在应用中使用位码时，情况可能会有所不同。上载失败时，Crashlytics无法象征和显示崩溃，并且Fabric仪表板上将显示“ Missing dSYM”警报。

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

注意：作为自动dSYM上传工具的替代方法，Fabric提供了命令行工具（upload-symbols），可以将其手动配置为在项目构建过程中运行。有关配置说明，请参见下面的上载符号部分。

...