Question

我在理解Apple从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和 0xffff0202 不同，这是预期的，因为该函数正在写入磁盘上的某些损坏的文件

我的第一个问题是为什么崩溃报告有时会被象征化（或部分符号化），有时则不是？（我刚开始分析它们，我们的构建系统没有保存为每个构建生成的dSYM文件，所以我不能做很多关于象征第二个的事情）

第二一个是崩溃报告如何从用户中获得符号化？当我查看项目时，发布版本的设置如下所示：对于ALL_BUILDS， GCC_GENERATE_DEBUGGING_SYMBOLS 设置为否，并且目标应用程序级别debug_information设置为矮人使用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，而不是符号化。符号化发生在Apple的服务器上。而且由于他们仍然收到了大量的崩溃报告（尽管只是真实情况的一小部分），他们只是为每组编写一份报告来减少他们服务器的负载。

第二个符号表示与第一个符号相同，因为内存地址相同。

问题2： Apple会使用应用二进制文件中的符号（如果它们未被删除）。他们不使用dSYM也不使用或不需要它。这种方式的缺点：您没有获得行号，二进制可执行文件大30-50％。相关构建设置为COPY_PHASE_STRIP。我假设你的情况设置为NO。

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

不同的崩溃报告但同样的崩溃？

1 个答案: