我正在使用macOS应用程序，该应用程序使用Google Crashpad将客户崩溃报告上传回给我们。该工具生成的故障转储在我们的应用中具有完整的符号，但在系统库中则没有。
这与位于/ Library / Logs / DiagnosticReports中的崩溃文件相反，该文件具有系统库的符号，但通常没有崩溃的应用程序的符号。
我的问题是，如何在系统库中符号化函数调用？对于已经使用atos和dSYM软件包构建的应用程序，我已经可以做到这一点。但是，我在查找有关如何对系统库执行此操作的文档时遇到麻烦。
Crashpad的文档不是很有启发性，因为它主要针对Linux和Windows：https://www.chromium.org/developers/decoding-crash-dumps
但是，从理论上讲，我应该能够做到这一点（毕竟，macOS的系统崩溃服务会在生成自己的报告时做到这一点-或者，也许我只需要从Xcode SDK传递一些调试信息到{{ 1}}？）
这是一个示例转储，其中删除了对我的应用程序的引用。
atos答案 0 :(得分：1)
我对Crashpad并不十分熟悉，但是通过查看报告，我认为我对发生的事情有所了解。
通常来说，您的符号化过程适用于您的图书馆或Apple的任何图书馆。您只需要将atos指向一个符号源，给它加载地址+偏移量就可以了。 dSYM是很好的源，但是可执行文件也可以是源。
但是，关键部分是可以访问符号源，该符号源与崩溃发生时加载到您的进程中的库的版本匹配相匹配。为了帮助完成此过程，Apple平台上的二进制文件由UUID标识。您可以使用dwarfdump -u /path/to/binary来读取此uuid。
执行此操作的一种方法是仅在发生崩溃的设备上尝试符号化过程。这就是ReportCrash的工作方式。而且，为什么它可以象征苹果的二进制文件。我认为它对您的应用程序无效的原因是您从工件中剥离了符号。
但是，以这种方式进行符号化有一些缺点。一个大问题是您通常无法使用dSYM。 dSYM包含更多的信息，而不仅仅是address-> Symbol info。因此，如果可以的话，您绝对想使用它们。
另一种方法是在事实之后进行符号处理，仅使用报告中的数据。这样做的最大问题是您仍然需要访问符号源。根据您再次发布的报告，Crashpad的符号系统似乎可以找到/加载dyld的符号。有用的是，它包括该特定二进制文件的uuid。但是，如果您没有碰巧附带10.9.5（13F1911）附带的行业副本，那您就不走运了。甚至无法访问10.9版的macOS SDK，因为您需要特定的构建。
鉴于CrashPad生成的警告很少，因此似乎至少应该尝试进行一些符号化。也许需要一些额外的配置？我知道Apple早在几年前就对符号查找API进行了一些修改（我相信是iOS 7时间框架），这使设备上的符号化过程更加复杂。从那以后可能不是CrashPad尚未更新吗？
这是托管崩溃报告系统存在的原因之一。 Crashlytics（我曾经使用的一项服务）会为所有平台的每个Apple OS版本编制索引，以便它可以执行高质量的服务器端符号来确切地解决此问题。还有很多其他服务。您是否考虑过托管解决方案？