5

XCode 3.2.5 でビルドされたアプリケーションの iTunesConnect のクラッシュログには、メソッド名が表示されますが、行番号は表示されません。たとえば、以下に貼り付けた要約クラッシュ レポートでは、次のように表示されます。

0x000f5ef8 -[MyTableViewController dealloc] + 120

ここで私を困惑させていることが 2 つあります。1 つ目は、iTunesConnect からの生の .crash ファイルが既に部分的にシンボル化されている理由です。クラスとメソッド名は表示されますが、ソース コード ファイルと行番号は表示されません。生の iTunesConnect クラッシュログが表示されることを期待します16 進数のアドレス。私が理解しているように、一度だけクラッシュ ログをローカル システムにダウンロードし、適切なツール (XCode Organizer、symbolicatecrash、atos、gdb x/i コマンドなど) を使用して明示的にバインドし、正確なアプリケーション バイナリおよび dSYM ファイル (一致する UUID を持つもの)、クラス、メソッド、ソース コード ファイル、および行番号の完全なシンボルが表示されますか? Windows ボックスでクラッシュログをダウンロードして表示しても、部分的にシンボル表示されます。ディストリビューション ターゲット設定で「Strip Linked Project」が設定されているにもかかわらず、この情報が生のクラッシュ ログに表示されるためには、ディストリビューション バイナリにデバッグ シンボルが含まれている必要があるのではないかと心配しています。ここでの洞察は素晴らしいでしょう。

私を当惑させている 2 番目のことは、この注目を集めたクラッシュを修正する上で、私にとってより差し迫った関心事である、オフセットのこのビジネスです。一致する UUID を持つ dSYM とアプリケーション バイナリを慎重に見つけ、ホーム ディレクトリに配置して、Spotlight などで見つけられるようにしました。何をしても、そのオフセット[MyTableViewController dealloc] + 120をソース コードに変換できません。ファイル (これは MyTableViewController.m であることがわかっています) と行番号です。生の iTunesConnect .crash ファイルを使用して、次のトリックを試しました。

  • XCode Organizer: その「シンボリック化」はクラッシュログへの変更には影響しません - それは同じです。
  • symbolicatecrash: 詳細モードでは何も文句を言わず、出力されるクラッシュログは同じです
  • gdb: XCode 3.2.5 がディストリビューション ビルドの生成に使用するのと同じ gdb および -arch 設定を使用し、この投稿ごとに一致するアプリケーション バイナリおよび dSYM シンボルをロードすると、gdb 'x/i' および 'info line *' コマンドが通知しますまったく別のファイルにあるコードベースのまったく無関係な部分に対応する私[MyTableViewController dealloc] + 120— .h ファイルですら! 野生のガチョウの追跡。

何かがおかしい。クラッシュ レポート、アプリケーション バイナリ、および dSYM ファイル全体でまったく同じ UUID を確保しているにもかかわらず、これらのツールのいずれも実際の行番号を生成することはできません。これを修正するには、正確な回線番号を知ることが重要です。社内でこのクラッシュを再現することができないため、ここでは盲目的に飛行しています。これは単純に過剰にリリースされたオブジェクトのように見えますが、それが正確にどのオブジェクトであるかは明らかではなく、コンテキストから判断することもできません。何らかの形でシンボリック化プロセスを壊している XCode ビルド設定の流用があるかどうか疑問に思っています。

御時間ありがとうございます!

以下は、iTunesConnect からの未加工の .crash ログの要約です。

Incident Identifier: 09EAE058-7D55-4AE5-947A-17280FB0211A
Hardware Model:      iPhone3,1
Process:         MyApp [1895]
Path:            /var/mobile/Applications/B4B872EF-CB0D-41D7-A7B5-435ADE479D0A/MyApp.app/MyApp
Identifier:      MyApp
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]

Date/Time:       2011-01-24 14:06:32.941 -0500
OS Version:      iPhone OS 4.2.1 (8C148)
Report Version:  104

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xd0000000
Crashed Thread:  0

Thread 0 Crashed:
0   libobjc.A.dylib                 0x33479466 objc_msgSend + 18
1   MyApp                       0x000f5ef8 -[MyTableViewController dealloc] + 120
2   CoreFoundation                  0x33a26f74 -[NSObject(NSObject) release]
3   libobjc.A.dylib                 0x3347a812 objc_setProperty
4   UIKit                           0x320bb4a0 -[UINavigationController setDisappearingViewController:]
5   UIKit                           0x320bb478 -[UINavigationController _clearLastOperation]
xx SNIP xx
23  MyApp                       0x00014eac main + 36
24  MyApp                       0x0000b324 start + 44

XX SNIP xx

Binary Images:
    0x1000 -   0x1e3fff +MyApp armv7  <5570f8eee3bc11647732c12f96fe9553> /var/mobile/Applications/B4B872EF-CB0D-41D7-A7B5-435ADE479D0A/MyApp.app/MyApp
4

1 に答える 1

0

保持されていない、または自動解放プールにあったオブジェクトを解放することで、同様の問題が発生したため、2回解放されました。多くの場合、フレームワーク/iOS 内にある場所でクラッシュが発生しますが、これは適切なメモリ管理の欠如が原因です。これがここで起こっていると言っているわけではありませんが、同様のエラーが発生したときに私が経験したことです.

于 2011-03-27T14:30:59.330 に答える