我在理解我从 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 处的KERN_INVALID_ADDRESS不同,这是可以预期的,因为函数正在写入磁盘上的一些损坏文件
我的第一个问题是为什么崩溃报告有时是象征性的(或部分象征性的)而其他时候不是?(我刚刚开始分析它们,我们的构建系统没有保存为每个构建生成的 dSYM 文件,所以我不能做太多关于符号化第二个的事情)
第二个问题是崩溃报告怎么可能来自用户的符号化?当我查看项目时,已发布版本的设置如下:对于ALL_BUILDS, GCC_GENERATE_DEBUGGING_SYMBOLS设置为NO,并且目标应用程序级别 debug_information 设置为 dSYM 文件相形见绌,生成调试符号设置为 No。(侧面问题:使用这些设置构建时,不会生成 dSYM,但如果我从 cMake(...) 神奇地将 GCC_GENERATE_DEBUGGING_SYMBOLS 设置为 true,则会生成 dSYM。当我阅读目标级别设置时,会覆盖构建级别设置)
对不起,很长的帖子,这是我的第一个。