ios - 不同的崩溃报告但相同的崩溃？

Question

我无法理解从 Apple 获得的这两个崩溃报告的一些内容:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x617401fa
Crashed Thread:  0
0   app                     0x0017c0ca Json::parse(int, JSON_value_struct const*) + 378
1   app                     0x0017bf46 Json::parse(void*, int, JSON_value_struct const*) + 2
2   app                     0x001302d2 JSON_parser_char + 2070
3   app                     0x0017bb58 Json::parse(std::string const&) + 356
4   app                     0x0008e682 NotificationData::ProcessNotifications(std::vector<UserEvent, std::allocator<UserEvent> >&) + 1062
5   app                     0x00106aea SMS::CheckNotifications() + 106
6   app                     0x001073dc SMS::update(Rex::TimeData const&) + 936
7   app                     0x00192c7e SceneManager::updateTick(TimeData const&) + 314
8   app                     0x001685ae Core::onRender(TimeData const&) + 522

和

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xffff0202
Crashed Thread:  0
0   app                     0x0017c0ca 0x1000 + 1552586
1   app                     0x0017bf46 0x1000 + 1552198
2   app                     0x001302d2 0x1000 + 1241810
3   app                     0x0017bb58 0x1000 + 1551192
4   app                     0x0008e682 0x1000 + 579202
5   app                     0x00106aea 0x1000 + 1071850
6   app                     0x001073dc 0x1000 + 1074140
7   app                     0x00192c7e 0x1000 + 1645694
8   app                     0x001685ae 0x1000 + 1471918

首先是一些事实:据说第一个发生的概率为 40%，第二个发生的概率为 35%。如果这是真的，这对我来说是一件好事。

根据我读到的有关这些东西的内容，我的推理是它们是同一个，因为函数的内存地址完全相同，只是 0x617401fa 处的 KERN_INVALID_ADDRESS 和 处的 KERN_INVALID_ADDRESS >0xffff0202 不同，这是预期的，因为该函数正在磁盘上写入一些损坏的文件

我的第一问题是为什么崩溃报告有时会被符号化(或部分符号化)，而有时则不会？ (我刚刚开始分析它们，我们的构建系统没有保存为每个构建生成的 dSYM 文件，因此我无法对第二个构建进行符号化)

第二个问题是如何从用户处获得崩溃报告？当我查看该项目时，已发布版本的设置如下:对于 ALL_BUILDS，GCC_GENERATE_DEBUGGING_SYMBOLS 设置为 NO，目标应用程序级别 debug_information 设置为 dwarf使用 dSYM 文件并生成调试符号设置为否。(附带问题:当使用这些设置构建时，没有 dSYM 生成，但如果我神奇地从 cMake(...) 将 GCC_GENERATE_DEBUGGING_SYMBOLS 设置为 true，则会生成 dSYM。我读到目标级别设置覆盖构建级别设置)

抱歉，帖子很长，这是我的第一篇文章。

Answer 1

事实是:iTunes 崩溃的 40% 都是由它造成的!到目前为止，这并不是您的应用程序发生的所有崩溃。 iTunes Connect 仅显示来自设备的崩溃，用户在设置设备时确实批准发送匿名使用数据(因为 iOS 5 可以稍后在设置应用程序中进行深入更改)。只有一小部分用户启用了此功能，因为他们不想被跟踪。在 iOS5 之前的系统上，崩溃报告也仅在设备与 iTunes 同步后才会发送。

简而言之:iTunes Connect 上的崩溃报告无法让您真正了解崩溃报告。以下是来自 Camera+ 开发人员关于这一事实的示例博客文章:http://taptaptap.com/blog/cameraplus-2-3-1-available-attack-of-the-crashinator/

这两个崩溃报告是相同的，你是对的。

问题 1:设备上的所有崩溃报告都会以未符号化的方式发送给 Apple。符号化发生在苹果的服务器上。而且由于他们仍然收到大量崩溃报告(即使只是实际发生情况的一小部分)，因此他们只代表每组一份报告，以减少服务器上的负载。

第二个符号将显示与第一个符号相同的结果，因为内存地址相同。

问题 2:Apple 使用应用程序二进制文件中的符号(如果未从应用程序二进制文件中删除这些符号)。他们不使用 dSYM，也没有或不想要它。这种方式的缺点:您无法获得行号，并且二进制可执行文件要大 30-50%。相关的build设置是COPY_PHASE_STRIP。我假设在您的情况下设置为NO。

关于设置级别:在 Xcode 中选择项目，然后选择目标，查看build设置不是Combined，而是Levels。最左边的值(已解析列)是正在使用的值。如果您在 .xcconfig 文件中使用build设置，它们通常是在项目级别的每个构建配置中设置的，如果设置不同，目标将覆盖这些设置。