iTunesConnectのcrashlogは部分的に記号化されています。行番号は表示されません

Question

私のXCode 3.2.5用のiTunesConnectのクラッシュログにはメソッド名が表示されますが、行番号は表示されません。例えば、私は以下に貼り付けてきた要約クラッシュレポートでは、このことを示しています

0x000f5ef8 -[MyTableViewController dealloc] + 120

私はいくつかの洞察力をいただければと思い、その上に私を困惑され、ここで二つのことがあります。最初の理由は、iTunesConnectから生まれた生の.crashファイルが、部分的に象徴化されている理由です。クラスとメソッドの名前は表示されますが、ソースコードファイルと行番号は表示されません。私は生のiTunesConnectのクラッシュログがと表示され、ちょうどの16進アドレスを表示すると期待しています。私が理解しているように、クラッシュログを自分のローカルシステムにダウンロードし、適切なツール（XCode Organizer、symboliccrash、atos、gdb x/iコマンドなど）と正確なアプリケーションバイナリとdSYMファイル一致するUUIDを持つ人）は、クラス、メソッド、ソースコードファイル、行番号の完全なシンボルを表示します。 Windowsのボックスにcrashlogをダウンロードして表示しても、部分的に象徴的に表示されます。私は自分の配布ターゲット設定に "Strip Linked Project"が設定されているにもかかわらず、自分の配布バイナリににいくつかのデバッグシンボルを含める必要があることを心配しています。ここの洞察はすばらしいことでしょう。

私に困惑しているこの2番目のことは、この高プロファイルのクラッシュを修正する際に直ちに懸念するものですが、オフセットのこのビジネスです。私は非常に慎重に一致するUUIDとdSYMとアプリケーションのバイナリを配置し、私のホームディレクトリにそれらを置くことができますので、私は何をしても、私はそのオフセット[MyTableViewController dealloc] + 120をソースに変換することができませんコードファイル（MyTableViewController.mとして知られています）と行番号です。

• XCodeオーガナイザ：その「記号」は、クラッシュログへの変更に影響を与えません。同じことです。
• symbolicatecrash：これは冗長モードでは何も文句を言わず、出力クラッシュログは同じです
• gdb：Xcode 3.2.5が配布ビルドの作成に使用するのと同じgdbと-arch設定を使用し、 this post、gdb 'x/i'、 'info line *'コマンドごとに一致するアプリケーションバイナリとdSYMシンボルをロードすると、[MyTableViewController dealloc] + 120は完全に異なるファイル内のコードベースの完全に無関係な部分に相当します。でも！野生のガチョウの追跡。

ここに何かがありません。クラッシュレポート、アプリケーションバイナリ、および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 

Answer 1

私は保持またはそれはそれによって二度リリースして得る自動解放プールにあったていなかったオブジェクトを解放すると同様の問題を経験してきました。多くの場合、フレームワーク/ iOSの中にあるが、適切なメモリ管理が不十分なためにクラッシュすることがよくあります。私はここでこれが起こっていると言っているわけではありませんが、似たようなエラーが現れたときに経験したことだけです。