为了符号化崩溃日志(终于成功了)，在阅读了所有这些答案之后，我认为这里有一些非常重要的地方没有被发现，以便确定为什么调用symbolicatcrash不能产生符号化输出。

在表示崩溃日志时，有3种资产必须组合在一起:

The crash log file itself (i.e. example.crash), either exported from XCode's organizer or received from iTunes Connect. The .app package (i.e. example.app) that itself contains the app binary belonging to the crash log. If you have an .ipa package (i.e. example.ipa) then you can extract the .app package by unzipping the .ipa package (i.e. unzip example.ipa). Afterwards the .app package resides in the extracted Payload/ folder. The .dSYM package containing the debug symbols (i.e. 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

在这个例子中，所有资产都适合在一起，您应该能够符号化您的堆栈跟踪。

接下来是符号化的崩溃脚本:

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

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

如果它不在那里，你可以运行一个查找。在你的Xcode中出现符号崩溃。应用程序目录找到它。

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

mdfind 'com_apple_xcode_dsym_uuids = *'

分别。

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

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

如果symbolicatecrash发现了你的.dSYM包，那么在symbolic .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包，那么在symbolic .log中应该有以下摘录:

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

如果所有这些资源都被symbolicatcrash找到，它应该打印出你的崩溃日志的符号化版本。

如果不是，你可以直接传入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

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

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

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

将推送到appstore的发布版.app文件、发布时创建的. dsym文件以及从APPLE收到的崩溃报告复制到一个文件夹中。 打开终端应用程序，进入上面创建的文件夹(使用cd命令) 执行命令atos -arch armv7 -o APPNAME。app /浏览器名称MEMORY_LOCATION_OF_CRASH。内存位置应该是应用程序根据报告崩溃的位置。

例如:atos -arch armv7 -o 'APPNAME。应用0 x0003b508”/“浏览器名称”

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

[classname functionName:];-510年

Symbolicating音标

如果我们使用IPA作为符号-只要用。zip重命名扩展名。IPA，然后我们就可以得到一个包含app的有效载荷文件夹。在这种情况下，我们不需要. dsym文件。

Note

这只能在应用程序二进制没有符号剥离的情况下工作。默认情况下，发布版本会删除符号。我们可以在项目构建设置“复制过程中的条带调试符号”中将其更改为NO。

更多细节请看这篇文章

我有点不爽的事实，这里似乎没有什么“只是工作”，所以我做了一些调查，结果是:

设置:接收报告的QuincyKit后端。没有任何象征意义，因为我甚至不知道他们在建议我怎么做才能让它起作用。

解决办法:从服务器在线下载崩溃报告。它们被称为“crash”，默认情况下进入~/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”结束(它想要一些。crash):

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

其次，在iOS端在QuincyKit BWCrashReportTextFormatter。m ~第176行，将@"[TODO]"改为@"TODO"以避开坏字符。

在运行symbolicate crash之前，我还将dsym、应用程序包和崩溃日志放在同一个目录中

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

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目录。你可以在这里找到这个实用程序:

/应用程序/ xcode /内容/ SharedFrameworks / DTDeviceKitBase.framework /更‌离子/ /资源/ symbolicatecrash

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

1-首先去itunesconnect下载你的崩溃日志。 注意:在大多数情况下，您可能会得到类似于“提交的报告太少而无法显示报告”的内容。基本上没有足够多的用户向苹果提交崩溃日志报告，在这种情况下，你什么都做不了。

2-现在如果你没有改变你的代码，因为你已经提交了你的二进制文件给苹果，然后启动Xcode的项目，并再次执行Product -> Archive。否则，只需找到您最近提交的二进制文件，并右键单击它。