iOSクラッシュレポートのバックトレースに屈しない

gistfile1.md

iOSクラッシュレポートのバックトレースに屈しない

アプリを実機のランニングテストで回していて運良くクラッシュを引き当てた時に、

Last Exception Backtrace:
0   CoreFoundation                	0x321d629e __exceptionPreprocess + 158
1   libobjc.A.dylib               	0x39e3297a objc_exception_throw + 26
2   CoreFoundation                	0x321208d4 -[__NSArrayM insertObject:atIndex:] + 764
3   YourApp                			0x0002fbf0 0x20000 + 64496
4   YourApp                  		0x0015e2c8 0x20000 + 1303240
5   YourApp                  		0x0002fa7a 0x20000 + 64122
...

↑このような微妙なヒントを与えられて頭がフットーしそうになった事は誰しも経験があると思います。

Archiveして.dSYMファイルを生成していれば比較的楽にシンボルを突き止める事が出来るのですが、普段のデバッグではそうそうArchiveなんてしませんし、もう次のビルドをしてしまっていてDerivedディレクトリにも痕跡が存在していないという状況がよくあると思います。

ただしここで、

• デバッグシンボルをストリップしておらず（Strip Debug Sybmols During Copy = NO)、
• クラッシュしたバイナリが実機にまだ存在している

場合は、atosを使用してソースコード上の位置を解析する事が出来ます。

実機からバイナリを抜き出す

iFunBox等で実機をUSBからファイルシステムとしてマウントし、対象のアプリのホームディレクトリから実行ファイルの現物をコピーしてきます。 <アプリ名>.app/<プロセス名>のファイルです。

atosでシンボル解決をする

上述の例でFoundation APIをコールする直前の

...
3   YourApp                			0x0002fbf0 0x20000 + 64496
...

↑ここの場所が知りたい場合は、

$ xcrun atos -o YourApp -l 0x20000 0x0002fbf0

と、拾ってきたバイナリ(YourApp)に対してコマンドを打ちます。うまくいけば例えば次のようにクラッシュしたソース上の位置が拾えます。

got symbolicator for YourApp, base address 4000
__37-[GlobalEvent gatherClientStatistics]_block_invoke (in YourApp) (GlobalEvent.m:145)

これでいつクラッシュしても安心ですね。

参考

http://stackoverflow.com/questions/10578155/matching-up-offsets-in-ios-crash-dump-to-disassembled-binary http://stackoverflow.com/questions/10707453/why-are-my-crash-reports-not-symbolicated https://developer.apple.com/library/ios/technotes/tn2151/_index.html#//apple_ref/doc/uid/DTS40008184-CH1-ANALYZING_CRASH_REPORTS

おそらくiOS9の現状では簡単に実行バイナリを実機から取得する手段は無いかもしれない。
iOS6~7で通用していたノウハウがどんどんdeprecateされている。