3

最近、私の iPhone アプリが「起動時にクラッシュするため」App Store から拒否されました。ただし、このクラッシュを再現できません。このアプリは、シミュレーターと、Apple がテストした同じハードウェアとソフトウェア (iOS 4 を実行する iPhone 3.1) を備えたデバイスの両方で完全に動作します。彼らが私に送ったクラッシュ ログには、"No Backtrace Available" と書かれているため、コードを調べる場所がありません。次に例を示します。

Incident Identifier: [...]
CrashReporter Key:   [...]
Hardware Model:      iPhone3,1
Process:         [MyApp] [1172]
Path:            /var/mobile/Applications/[...]-3F1B-4504-A572-[...]/[MyApp].app/[MyApp]
Identifier:      [MyApp]
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]

Date/Time:       2010-07-08 [...]
OS Version:      iPhone OS 4.0 (8A293)
Report Version:  104

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xfe42c648
Highlighted Thread:  0

Backtrace not available

Unknown thread crashed with ARM Thread State:
    r0: 0x00002388    r1: 0x00000000      r2: 0x3e2b47c8      r3: 0x00000108
    r4: 0x2fe00000    r5: 0x00000000      r6: 0x00000000      r7: 0x00000000
    r8: 0x2ffffb48    r9: 0x2fffecfc     r10: 0x00000000     r11: 0x00000000
    ip: 0x00000010    sp: 0x2ffffb4c      lr: 0x2fe08907      pc: 0xfe42c648
  cpsr: 0x40000010

Binary Images:
    0x1000 -    0x78fff +[MyApp] armv7  <23af3d265c3086eaceb51cc649eb794f> /var/mobile/Applications/[...]-3F1B-4504-A572-[...]/[MyApp].app/[MyApp]
0x2fe00000 - 0x2fe26fff  dyld armv7  <697ae459733a7f0b6c439b21ba62b110> /usr/lib/dyld
[many more libraries...]

これをデバッグするにはどうすればよいですか? これはコーディングのバグではなくビルドの問題である可能性はありますか? また、クラッシュ レポートの「ARM スレッドの状態」または「バイナリ イメージ」の部分から有用な情報を抽出できますか?

ありがとう！

*更新: * iOS 4 を実行している別の iPhone に初めてアプリをインストールしましたが、まだクラッシュを再現できません。これは、ライブラリやターゲット バージョンなどのビルド時のパラメーターの問題であると考え始めています。クラッシュ レポートに基づいて、アプリケーションのコードが実行された可能性はありますか?

4

4 に答える 4

1

テクニカル ノート TN2151: iPhone OS アプリケーション クラッシュ レポートの理解と分析を参照してください。シンボリケーションは通常、クラッシュの原因を追跡するのに役立ちますが、バックトレースがないため、このインスタンスでは役に立たない場合があります。

シミュレーターでテストする必要はありません。シミュレータ ビルドとデバイス ビルドは、2 つの異なるハードウェアに対して完全に個別にコンパイルされます。シミュレーターで実行されるからといって、デバイスの障害については何もわかりません。

Apple は、他のアプリがほとんどのメモリを消費する iOS4 でアプリを起動するなどして、アプリのストレス テストを行うことを覚えておいてください。テストデバイスでも同様に行う必要があります。

Apple が行っているテストを再現するには、おそらくテスト デバイスをデフォルトに戻す必要があります。次に、独自のアプリを起動する前に、考えられるすべてのアプリを開きます。

于 2010-07-11T12:19:18.320 に答える
1

ARM スレッドの状態からいくつかの情報を作成できます。PC レジスタは、クラッシュ レポートで問題になっている無効なアドレスを含む唯一のレジスタです。これは、アプリがそのアドレスでコードを実行しようとしたことを意味します。

SIGSEGV は、問題のアドレスが無効であることを意味します。システムは、このアドレスでメモリ ページをセットアップしていません。

iOS では任意のアドレスから単純にコードを実行できるとは思いませんが、スタック フレームが壊れていて、関数が返されたときに戻りアドレスが無効だった可能性があります。これは、「バックトレースが利用できない」問題をサポートしています。

スタックのファウリングは、バッファ オーバーランの結果である可能性があります。ローカル変数配列で memcpy またはセットのループを使用し、配列の末尾をオーバーランすると、スタックが破壊される可能性があります。

于 2011-12-13T20:06:55.273 に答える
0

クラッシュを再現できませんでした。いくつかのビルド パラメータをいじって再送信したところ、承認されました。

于 2010-08-08T21:33:47.380 に答える
0

segfault がビルド エラーである可能性は低いです。この問題を再現するには、プロジェクトを実行する前に、iPhone シミュレーターに保存されている情報をすべて消去してみてください。自分の iPhone には存在するが、デフォルトのインストールでは使用できない特定のエントリが NSUserDefaults に存在すると想定している可能性があります。それでも問題が再現しない場合は、コンポーネントごとに単体テストを作成し、各コンポーネントを一度に失敗の原因として除外する必要があります。最終的には、失敗の真の原因を除いて、失敗のすべての原因を除外することになります。

于 2010-07-11T06:53:13.557 に答える