0

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が生成されます。ターゲットレベルの設定を読み取ると、ビルドレベルの設定が上書きされます)

長い投稿でごめんなさい、それは私の最初のものです。

4

1 に答える 1

0

事実に関して:iTunesが受けるクラッシュの40%です!これは、アプリで発生するすべてのクラッシュではありません。iTunes Connectは、デバイスからのクラッシュのみを表示します。ユーザーは、デバイスのセットアップ時に匿名の使用状況データの送信を承認しました(iOS 5は、後で設定アプリで深く変更できるため)。そして、追跡されたくないので、それを可能にするのはごく一部のユーザーだけです。iOS5より前のシステムでは、デバイスがiTunesと同期された後にのみクラッシュレポートも送信されます。

つまり、一言で言えば、iTunes Connectのクラッシュレポートでは、クラッシュレポートを実際に表示することはできません。Camera +開発者からのこの事実に関するブログ投稿の例:http://taptaptap.com/blog/cameraplus-2-3-1-available-attack-of-the-crashinator/

これらの2つのクラッシュレポートは同一です、あなたは正しいです。

質問1:デバイス上のすべてのクラッシュレポートは、記号ではなくAppleに送信されます。象徴化はAppleのサーバーで起こります。そして、彼らはまだ非常に多くのクラッシュレポートを受け取っているので(実際に起こっていることのほんの一部ですが)、サーバーの負荷を減らすために、グループごとに1つのレポートのみを象徴しています。

メモリアドレスが同一であるため、2番目の記号は最初の記号と同じ結果を示します。

質問2: Appleは、アプリバイナリからシンボルが削除されていない場合、それらのシンボルを使用します。彼らはdSYMを使用しておらず、dSYMを持っている、または望んでいません。この方法の欠点:行番号が取得されず、バイナリ実行可能ファイルが30〜50%大きくなります。関連するビルド設定はCOPY_PHASE_STRIPです。あなたの場合はに設定されているNOと思います。

設定レベルについて:Xcodeでプロジェクトを選択し、次にターゲットを選択します。ビルド設定をとしてではなく、として表示しCombinedますLevels。左端の値(解決済みの列)が使用されている値です。.xcconfigファイルでビルド設定を使用している場合、それらは通常、プロジェクトレベルでビルド構成ごとに設定されます。異なる設定の場合、ターゲットはこれらを上書きします。

于 2012-08-23T18:02:27.030 に答える