Objective-Cスタックトレースの読み方
私は次のスタックトレースを持っています：
0 MyApp 0x000833a3 +[TFCrashHandler backtrace] + 26
1 MyApp 0x000836bd TFSignalHandler + 28
2 libsystem_c.dylib 0x33eac727 _sigtramp + 34
3 ??? 0x00000002 0x0 + 2
4 MyApp 0x000803f1 msgpack_unpack_next + 112
5 MyApp 0x0007faeb +[MessagePackParser parseData:] + 74
6 MyApp 0x0007f84b -[NSData(NSData_MessagePack) messagePackParse] + 26
7 MyApp 0x000254c3 +[Http get:params:cacheMins:msgPack:complete:] + 146
...
そして、私はそれをどのように読むのか疑問に思っています：
- 私は下から上に行くと仮定します。たとえば、7行目は6行目、5行目などです。
- 4行目の「+112」はどういう意味ですか？それはクラッシュしたコードファイルの行番号ですか？
- '???'は何ですか3行目はどういう意味ですか？
どうもありがとう
0 MyApp 0x000833a3 +[TFCrashHandler backtrace] + 26
クラッシュは+[TFCrashHandler backtrace] +26から生成されました。そのシンボル位置+26バイトにある命令から。
それが本当にスタックトレースの一番下にあり、そこでクラッシュした場合は、TCrashHandlerが実際のクラッシュを覆い隠しています。実際のクラッシュは、上記の数フレームのように見えます。
1 MyApp 0x000836bd TFSignalHandler + 28
TFSignalHandlerは+ backtraceと呼ばれるものでした。
2 libsystem_c.dylib 0x33eac727 _sigtramp + 34
Ewww ...信号トランポリン。アプリがシグナルを受信し、トランポリンがTFSignalHandler（）を呼び出すように設定されました。
シグナルハンドラーがランダムスレッドで呼び出される場合があります。つまりこの特定のクラッシュがパーサーとは何の関係もなく、どこか別の場所でのクラッシュと関係がある可能性はごくわずかです。ただし、パーサーについて詳しく知らなくても、悪意のある入力に対して強化されているかどうかは疑問です（これにより、このようなクラッシュが発生する可能性があります）。
3 ??? 0x00000002 0x0 + 2
スタックは解読できませんでした。無視します。意味がない。最良の場合;コンパイラ最適化からのフォールアウト。最悪の場合;誰かがスタックにうんちをし、バックトレースメカニズムが何が起こっているのか理解できません（ほとんどありません-通常、スタックのうんちは完全なバックトレースを妨げるほどに飛び散ります）。
4 MyApp 0x000803f1 msgpack_unpack_next + 112
Ooooh ...トリッキー。誰かがCを使用して解析しています。そしてそれは墜落した。エントリポイントから関数までの112バイトの命令はすべて、boomになりました。しかし、実際にはそうではありません。シグナルハンドラーを呼び出し、それによって処理されたからです。これはまだブームですが、シグナルハンドラーは追加の法医学的証拠を効果的に破壊しました。
「トリッキー」なコメントは、Cの大きな山に対して最適化コンパイラがフレームを崩壊させて、この関数よりかなり下の関数でクラッシュが発生した可能性があることを示しています。
5 MyApp 0x0007faeb +[MessagePackParser parseData:] + 74
物事がひどくうまくいかなかったとき、MessagePackParserは解析していました。
6 MyApp 0x0007f84b -[NSData(NSData_MessagePack) messagePackParse] + 26
7 MyApp 0x000254c3 +[Http get:params:cacheMins:msgPack:complete:] + 146
ああ...はい....誰かがHTTPからいくつかのデータを取得し、それが不正な形式であったため、クラッシュが発生しました。
結論;パーサーが偽の入力を受け取り、クラッシュしました。バックトレースを作成することで支援しようとするシグナルハンドラーが配置されていましたが、明らかに、これ以上の情報は明らかになりませんでした。ロングショットの代替手段は、信号が別の場所で生成され、このスレッドがランダムに選択されて処理されることです。このクラッシュを一貫して再現できる場合は、ランダムスレッド信号の場合はほとんどありません。
入力データのキャプチャがあるか、msgpack_unpack_next（）がどのようにクラッシュするかを何らかの方法で推測できない限り、詳細情報を提供しないと運が悪くなります。
'???'識別できないものであり、おそらくシンボルなしでコンパイルされたコードですが、他の何かである可能性もあります。