BLOG

2014年4月22日/ .crash, .dSYM, iOS

[iOS] アプリのクラッシュログを解析する方法

 

iOSアプリがクラッシュするとログが保存され、xCodeのOrganizerからログを取得して解析することができます。

またApp Storeへの申請でアプリの審査後にアップルからリジェクトされた場合で、リジェクト理由がクラッシュだった場合は同じくクラッシュログが送られてきます。

 

いずれもユーザーの手順などがわからず頼りになるのはこのクラッシュログなのですが、ログはメモリダンプなのでアドレスが書かれてあるだけで何が起こっているかパッと見ではわかりません。

そこで、各メモリのアドレスをシンボルで読めるようにして、クラッシュ時に実行された処理を解析することでログを手がかりにクラッシュ原因を探ることになります。

 

今回はクラッシュログからシンボル(どのファイルのどの行でクラッシュしているか?)を確認する方法について紹介します。

※ この記事を書いた現在の環境は[iOS:7.1][xCode:5.1]です。

 

 

解析に必要なファイル

まず解析に必要なファイルは2つあります。

1つ目はクラッシュログである「.crash」ファイル、もう一つは「.dSYM」ファイルです。

 

 

.dSYMファイルとは?

.dSYMファイルはデバックシンボル群を保存するファイルで、このファイルがあればアドレスしか書かれていない.crashファイルからシンボルを確認することができます。

アプリビルド時に生成されるものなので、.crashのログが出力されたバイナリと同じビルドで生成された.dSYMファイルでなければ解析できないので注意して下さい。

 

 

.dSYMファイルの保存場所

先の説明の通り.dSYMファイルはアプリビルド時(アーカイブ)に生成され、下記パスに保存されます。

 

/Users/[ユーザー名]/Library/Developer/Xcode/DerivedData/[プロジェクト名]-[ランダムな文字列]/Build/Products/Debug-iphoneos/[プロジェクト名].app.dSYM

 

ここで注意なのが、ビルド時には上書いてしまうことです。

App Storeへの申請でアーカイブした後で、同じプロジェクトからアーカイブを実行してしまうと別のデバックシンボルとなってしまうため、アップルのレビューが通過するまでは保存しておくことをオススメします。

 

ただ、万が一消してしまった場合で、アーカイブファイルが残っていた場合はそのアーカイブファイルから.dSYMを取得することは可能なので、こちらの下記手順でも問題はありません。 

ss01

Organizerのアーカイブファイルから「Show in Finder」を選択します。

 

ss02

アーカイブファイルから「パッケージの内容を表示」を選択します。

 

ss03

そうすると、.dSYMファイルがあるのでこれを使用します。

 

symbolicatecrashまでのシンボリックリンクを生成

xCodeの中には.dSYMのデバックシンボル群を解析しシンボルを割り当ててくれるツール「symbolicatecrash」があります。

これを実行するにはターミナルからコマンドで実行することになるのですが、「symbolicatecrash」までのパスが非常に長いため今回はシンボリックリンクを生成しました。

 

$ sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash ./symbolicatecrash

※ xCode:Ver5.1時点のパスです。

 

 

シンボルを確認する

「symbolicatecrash」「.crash」「.dSYM」が揃ったのでいよいよシンボルを読み込みます。

ターミナルを起動して下記コマンドを実行して下さい。

 

$ symbolicatecrash [アプリ名].crash [アプリ名].app.dSYM/

 

この時、

Error: “DEVELOPER_DIR” is not defined at …

このようなエラーが表示される場合は下記を実行して、DEVELOPER_DIRまでのシンボリックリンクを生成して下さい。

 

$ export DEVELOPER_DIR=”/Applications/Xcode.app/Contents/Developer/”

 

もう一度下記コマンドを実行します。

 

$ symbolicatecrash [アプリ名].crash [アプリ名].app.dSYM/

 

すると、.crashのメモリダンプの表示ではアドレスのみですが、シンボルが表示されるようになったのがわかると思います。

 

 

ss04

.crashのThread 0 の実行部分。

アドレスしか表示されていないので、アプリが具体的にどのような処理を実行した時に出力されたダンプなのかがわかりません。

 

 

ss05

アドレスにファイル名など実行したシンボルが表示され、今回のケースではMainViewControlerのUITableView関連の処理でクラッシュしたことがわかりました。

 

 

まとめ

いかがでしたでしょうか?

アプリのローンチ後はクラッシュログを解析することがあると思いますが、シンボルが確認できるだけでもかなり有益な情報となりえます。

是非理解して品質向上に役立てて下さい。

 

参考:

アプリがクラッシュしちゃった。さて、どうしましょう- Part 1

 

 

Resent Posts

Category