15

お気づきのように、logcat は次のように常に 34 行のクラッシュログを返します。

4cf7c700  401c0000 
4cf7c704  48463ff0 
4cf7c708  44d11f7c  
4cf7c70c  afd0cd89 
4cf7c710  00000000  
4cf7c714  82ab29dc  libmyproject.so
4cf7c718  00000000  
4cf7c71c  4cf7c73c  
4cf7c720  836c44f0  libmyproject.so
4cf7c724  82f3a414  libmyproject.so
4cf7c728  4cf7c768  
4cf7c72c  0000008d  
4cf7c730  007ea0a8  [heap]
4cf7c734  00270100  [heap]
4cf7c738  e3a07077  
4cf7c73c  ef900077  
4cf7c740  00000000  
4cf7c744  4cf7c774  
4cf7c748  836c44f0  libmyproject.so
4cf7c74c  00000000  
4cf7c750  836c44f0  libmyproject.so
4cf7c754  82f63768  libmyproject.so
4cf7c758  00000000  
4cf7c75c  4cf7c7e4  
4cf7c760  00000000  
4cf7c764  00000001  
4cf7c768  00000000  
4cf7c76c  0badc0de  
4cf7c770  fffffff8  
4cf7c774  00000000  
4cf7c778  00000168  
4cf7c77c  00000009  
4cf7c780  00000200  
4cf7c784  00000000

ただし、スタックもに保存されることはわかっています/date/tombstones/tombstone_0[0-9]。そこでは、他の多くのスタックを見つけることができ (それらがどこから来たのか完全には理解できません)、それらのいくつかは前述のスタックの 2 倍の長さです。

アプリケーションのクラッシュから非常に長いスタック ダンプを取得するにはどうすればよいですか?

4

2 に答える 2

31

debuggerd と呼ばれる Android のクラッシュ処理プログラムは、スタックの一部のみをログに書き込みますが、スタック全体を tombstone ファイルに書き込みます。これは、system/core/debuggerd/debuggerd.c にハードコーディングされています。

_LOG() の呼び出しについては、ルーチン debug_stack_and_code() を参照してください。_LOG の 2 番目のパラメーターは、データを廃棄 (tombstone) のみに送信するか、ログと廃棄 (tombstone) に送信するかを制御します。

が表示されている場合は(sp_depth>2||only_in_tombstone)、2 を別のものに変更して、ログに報告されるより深いスタック フレームを取得できます。これは、システム上で debuggerd を再コンパイルして置き換えることができることを前提としています。そうでない場合は、トゥームストーン ファイル自体を調べて、より長いスタック ダンプを探すことになります。

ダンプは、プログラムが Linux でクラッシュしたときに debuggerd によって作成されます。これが発生すると、カーネルは死にかけているプログラムにシグナルを送信します。このシグナルは、すべてのネイティブ Android アプリにインストールされている特別なシグナル ハンドラーによってキャッチされます。バイオニック C ライブラリによる。シグナル ハンドラーは (名前付きパイプを介して) debuggerd に接続し、ptrace を使用して死にかけているプログラムに接続し直して、レジスタとメモリを読み取り、廃棄 (tombstone) とログ エントリを生成します。

于 2011-12-08T02:21:19.747 に答える