symbolicateを使わずにクラッシュログを(部分的に)解析する

最近、Appleのアプリ審査にmacOS用アプリをサブミットしましたが、残念ながらアプリがクラッシュしたらしく、クラッシュログが送られてきました。なんとも扱いに困ったもので、色々試した上で上手くいった結果を書こうと思います。

概要

• クラッシュログ(.crashファイル)を解析する準備をする
• クラッシュログが与えられた状況で、そのアプリがクラッシュしたときの原因ファイルとその行番号を取得する

準備

1. 分かり易くするため、解析用のディレクトリ(今回はcrashというディレクトリを作った想定)をどこでもいいので作っておきます。
2. クラッシュログをiTunes　Connectからダウンロードして、crashディレクトリに入れます。
3. 次に、クラッシュしたアプリ(提出したバージョン)をXcodeから掘り起こします。



WindowのOrganizerを開きます。



Archiveしたときの画面がでてくるので、自分が提出したバージョンを選びます。



Finderで表示します。



パッケージの内容を表示して、Products/Applications/にある自分のアプリをcrashディレクトリにつっこみます。



4. クラッシュログを開いて、こんな感じに書かれている部分を探します。(アドレスがいっぱいのところ) そのなかで、自分のアプリの識別子があると思うので、その後に続くアドレス2つを使います。



5. 最後に、次のコマンドを実行します。ターミナルでの操作になります。crashディレクトリに移動してから実行してください。

atos -o <アプリ名>.app/Contents/MacOS/<アプリ名> -arch x86_64 -l <短い方のアドレス> <長い方のアドレス>

今回の例なら、


atos -o Welemfine.app/Contents/MacOS/Welemfine -arch x86_64 -l 0x102abf000 0x0000000102ac2878

となります。

実行結果

なにやらWeatherViewController.swiftの73行目(NSCollectionViewのコールバック関数内)でクラッシュしたようです。デバッグせねばっ...!!!

まとめ

本当はsymbolicateを使ってうまい具合に解析できれば良かったんですが、クラッシュレポートのバージョンが合わないとエラーが出て、一筋縄ではいきませんでした。また、すぐに対応する必要があったためこのような手法をとりました。あと、iOSのクラッシュログ解析の情報は割とありますね。

参考