CrashReporterでクラッシュの原因を特定する方法

PeyPey Tips コメントを投稿する

多くのユーザーが使用しているであろうCrashReporter。インストールしていて、クラッシュのたびにバナー通知が表示されているが、実際のところ使い方がイマイチわからないというユーザーも少なくはないはずだ。

 

CrashReporterを使用すると、原因を特定できる可能性がある。確実に特定できるというわけではないので、役に立たないと思ってしまうユーザーもいるだろう。しかし開発者に問合せたり、他の人に聞いたりする前に一度確認してみると自分で解決できるかもしれないので是非試して欲しい。

 

また、iCleaner Proを使用して原因を特定することもできるが、気が付かないうちにクラッシュする時や、特定の動作や起動させた時など明確に原因がわからない場合はiCleanerでも特定しにくい。CrashReporterは開発者ではなくても、ある程度自分で特定することも可能なので、以下で説明する簡単な手順を試して欲しい。

以下で説明する方法は正しい使い方として紹介しているわけではなく、使い方の一例として説明したものである。

※本記事は脱獄（Jailbreak）iOSデバイス向けの記事です。脱獄していないデバイスでは動作しません。脱獄や脱獄後に関しては以下のリンクを参考にして下さい。

脱獄Q&A : 脱獄(JailBreak)とは?よくある質問や脱獄後の質問など

1. CrashReporterのインストール

CrashReporterはiOSアプリやiOS内で発生したクラッシュの詳細を確認できるものであり、クラッシュ時の時刻やクラッシュ時に起動していたサードパーティ製のアプリなど、細かなところまで確認できるものである。

CrashReporterはBigBossから無料でインストール可能だ。

インストールが完了したら、ホーム画面上にあるCrashReporterアイコンをタップして起動してみよう。

 

2. CrashReporterの起動

起動すると、メインビューにクラッシュが発生して記録されていた場合は画像のようにクラッシュが発生した全てのプロセスが表示されている。（初めてインストールした場合は何も表示されないことがある）

いくつかのカテゴリに分かれて表示されており、確認できたのは以下の3つのカテゴリである。

  • Apps
  • App Extensions
  • Services (Daemons, etc.)

またCrashReporter内には以下のように記載されている。

Appsには最も一般的なiOS上で動作するタイプで、その殆どのアプリはホーム画面上にアイコンがあり、起動するとフルスクリーンウィンドウで表示されるものである。例えばメモ、電話、天気などがあり、スプリングボードと呼ばれるホーム画面を意味するものもAppsに含まれている。

App Store経由でインストールした多くのアプリもここに表示される。

App ExtensionsはAppleがiOS 8の時に導入したいくつかのアプリケーションに機能を追加するなどの、アプリを拡張する小さなプログラムである。拡張機能の種類にはキーボードや共有メニュー、通知センターの今日タブのウィジェットなどの拡張が含まれる。

Servicesはグラフィカルユーザインタフェース（GUI）を持っていないプログラムである。Serviceカテゴリはエージェントとデーモンを含む、特定のタスクを実行するためにバックグラウンドプロセスとして起動する小さなプログラムである。

このようなプログラムは多くの場合、必要なときにのみ実行するように設計されている。

サービスを無効にするツールがあるが、一般的にはあまり良いアイデアだと言えない。その理由として、それらを無効にすると機能を削除してしまったり他のプログラムを間違って実行したりすることもある。サービスとのトラブルに直面した場合は、単純にサービスを向こうにするのではなく、問題を解決することをおすすめする。

3. プロセスを選択

CrashReporterを起動し、クラッシュしたプロセスの一覧から選択する。赤文字で「Latest: less than 1 hours ago.」と書かれているものがあれば、1時間以内にクラッシュしたことを意味する。

プロセスを選択すると、LatestとEarlierの2つに別れて表示される。Latestは一番新しいものでありEarlierはそれ以前のものを意味する。またそれぞれの項目には日付が記載されているのでわかりやすい。

たくさんある場合ほど特定しやすい。一番古い日付の時から同じクラッシュが頻繁に発生していることになるため、日付の古い時から一番新しい日付の間でインストールしていたTweakに一致するものがある場合は、一致するTweakが問題を引き起こしていた犯人である可能性が高くなる。

 

注意：

Latestは最新のクラッシュを表示する項目であるが、最新のクラッシュを表示できていない可能性もある。最新のクラッシュレポートは既に削除されている可能性や記録されていない可能性もある。

iOSはプログラムのために記録されたレポートの数を制限しており、制限を超過すると、新しいレポートが記録されなくなる。これを解決するにはこのプログラムの古いクラッシュレポートを削除する必要がある。

 

4. 日付を選択して詳細画面へ

ここでは選択したプロセスがクラッシュした時の詳細な情報を確認できる。ここでも以下の4つのカテゴリに分けて表示されている。

  • Crashed Process
  • Main Suspect
  • Other Suspects
  • Loaded Libraries (3rd Party)

Crashed Processはそのままの意味でクラッシュしたプロセスを意味する。

Main Suspectはクラッシュした原因である可能性が最も高いとCrashReporterが判断したものである。もちろんCrashReporterの検出が完璧であるとは限らないため、あくまで可能性があると考える。

Other SuspectsもMain Suspectと同じく可能性があるものである。Main Suspectと同様にCrashReporterが判断したもので、完璧な検出ではないため、原因である可能性があるとして考える。

Loaded Libraries (3rd Party)はプロセスがクラッシュした時にロードされていたライブラリのリストである。これらのライブラリの中に原因がある可能性もある。

 

5. crash logを確認する

上記までの手順で確認できることもあるが、出来なかった場合には、下の方にある青いView crash logをタップしてcrash logを見る。タップすると複雑な文字列が大量に表示されている。

ここではクラッシュした時の状態を確認することができ、画像では例えば以下のようなことがわかる。

  • iPhone 7,1のデバイスである
  • SpringBoardでクラッシュしている
  • 2015年11月5日 17:28:31にクラッシュしている（起動から27秒後）
  • 2015年11月5日 17:28:58に起動している
  • iOS 9.0.2のデバイスである

その他にも多くの情報が書かれているが、このcrash logでは「Last Exception Backtrace」や「Thread」で表示されているものを見るのが有効である。具体的には問題があったものには「+」が付いている事が多い。

画像の例ではTouchPose.dylibの前に「+」が付いていることがわかる。このことからTouchPoseが犯人である可能性が高いことがわかる。

 

6. Syslogを確認する

Syslogも複雑な大量の文字列が表示される。ここでは、CrashReporterが記録したレポートをクラッシュが発生した時系列で確認できる。View syslogをタップして開いてみよう。

Syslogを見てクラッシュの原因を特定できる場合は、以下の文字が記載されている文字の少し上に書かれていることが多いようだ。ほとんどの場合はsyslog内の下の方に記載されている。

ReportCrash (Crash Reporter) : Formulating report・・・

この画像の場合、Searchdでクラッシュが頻発していた時のレポートだ。ReportCrashの上の行を確認すると、ActionMenu.dylibとActivator.dylibの2つが記載されていることがわかる。

どちらかが原因である可能性が高いため、1つずつ停止してしばらく様子を見たところ原因はActionMenuだったという事がわかった。

 

他にもReportCrashの行の上に「reason: ‘-[xxxxxxx]: 」と記載されている場合には具体的にクラッシュした原因を特定できるメソッドなどが書かれていることがある。クラスがわかればそのメソッドを使用しているTweakを特定できることもある。

 

まとめ

クラッシュが頻発していた場合などでCrashReporterで記録されている場合は、CrashReporterで以下の様なことを試してみる。

  1. 問題の項目を選択し、LatestやEarlierにMain Suspectがあれば、まずはそれを疑ってみる
  2. Earlierの中で一番古いものとLatestで動作していたものを見比べてみて可能性を絞る
  3. View crash logをタップして「+」マークが付いているものがないかを見てみる
  4. View syslogをタップしてReportCrashの行の上を確認してみる

また、セーフモードになってしまったり、CrashReporterではわからない場合、まずはiCleaner Proを使って確認してみる。