Appleから受け取ったこれら2つのクラッシュレポートについていくつか理解するのに問題があります。
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%の確率で発生し、2回目は35%の確率で発生すると言われています。これが本当なら、それは私にとって非常に良いことです。
私がこのことについて読んだことに基づく私の推論は、関数のメモリアドレスがまったく同じであるため、それらは同じであるということです。0x617401faのKERN_INVALID_ADDRESSと0xffff0202のKERN_INVALID_ADDRESSだけが異なります。これは、関数が書き込みを行っていたために予想されます。ディスク上のいくつかの破損したファイル
私の最初の質問は、クラッシュレポートがシンボル化される(または部分的にシンボル化される)場合とそうでない場合があるのはなぜですか?(私はちょうどそれらを分析し始めました、そして私たちのビルドシステムはビルドごとに生成されたdSYMファイルを保存していなかったので、2番目のものを象徴することについて多くのことをすることができません)
2つ目は、クラッシュレポートをユーザーからどのように象徴化できるかということです。プロジェクトを調べたところ、リリースされたビルドの設定は次のようになっています。ALL_BUILDSのGCC_GENERATE_DEBUGGING_SYMBOLSはNOに設定され、ターゲットアプリケーションレベルのdebug_informationはdSYMファイルでdwarfに設定され、デバッグシンボルの生成はNoに設定されています。質問:これらの設定でビルドされた場合、dSYMは生成されませんが、cMake(...)からGCC_GENERATE_DEBUGGING_SYMBOLSを魔法のようにtrueに設定すると、dSYMが生成されます。ターゲットレベルの設定を読み取ると、ビルドレベルの設定が上書きされます)
長い投稿でごめんなさい、それは私の最初のものです。