| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
Oracle Solaris Studio 12.2: dbx コマンドによるデバッグ |
デバッグ時ディレクトリへのコンパイル時ディレクトリのマッピング
dbx を完全にサポートするために -g オプションを必要とする共有ライブラリ
コアダンプしたプログラムが共有ライブラリと動的にリンクしている場合、それが作成された同じオペレーティング環境でコアファイルをデバッグすることが重要です。dbx では、一致しないコアファイル (たとえば、バージョンまたはパッチレベルの異なる Solaris オペレーティングシステムで生成されたコアファイル) のデバッグに対しサポートが制限されます。
注 - ネイティブコードのときと異なり、コアファイルから Java アプリケーションの状態情報を入手することはできません。
コアファイルをデバッグするには、次のように入力します。
$ dbx program_name core
または
$ dbxtool program_name core
次のように入力すると、dbx は program_name をコアファイルから決定します。
$ dbx - core
または
$ dbxtool - core
dbx がすでに起動していれば、debug コマンドを使用してコアファイルをデバッグすることもできます。
(dbx) debug -c core program_name
プログラム名として - を指定すると、dbx はコアファイルからプログラム名を抽出します。実行可能ファイルのフルパス名をコアファイルから抽出できない場合は、実行可能ファイルを特定できないことがあります。この場合は、dbx でコアファイルを読み込むときに、バイナリの完全なパス名を指定します。
コアファイルが現在のディレクトリに存在しない場合、パス名を指定できます (/tmp/core など)。
プログラムがコアをダンプしたときにどこで実行されていたかを確認するには、where コマンド (「where コマンド」を参照) を使用してください。
コアファイルをデバッグする場合、変数と式を評価して、プログラムがクラッシュした時点での値を確認することもできますが、関数呼び出しを行なった式を評価することはできません。シングルステップは実行できません。ブレークポイントを設定して、プログラムを戻すことができます。
コアファイルの読み込みに問題がある場合は、コアファイルが切り捨てられているかどうかを確認してください。コアファイルの生成時に、コアファイルの最大サイズの設定が小さすぎる場合は、コアファイルが切り捨てられ、dbx で読み込めないことがあります。C シェルでは、limit コマンドを使用して、コアファイルの最大サイズを設定することができます (limit(1) マニュアルページを参照)。Bourne シェルおよび Korn シェルでは、ulimit コマンドを使用します (limit(1) マニュアルページを参照)。シェルの起動ファイルでコアファイルのサイズの上限を変更してその設定を有効にし、コアファイルを生成したプログラムを再実行すれば、完全なコアファイルが生成されます。
コアファイルが不完全で、スタックセグメントが欠落している場合、スタックのトレース情報は利用できません。実行時リンカー情報が欠落している場合、ロードオブジェクトのリストは利用できません。この場合は、librtld_db.so が初期化されていないというエラーメッセージが表示されます。LWP のリストがない場合、スレッド情報、LWP 情報、およびスタック追跡情報は利用できません。where コマンドを実行すると、プログラムが「有効」ではなかったことを示すエラーメッセージが表示されます。
特定のシステム (コアホスト) で作成されたコアファイルを、デバッグのためにそのファイルを別のマシン (dbx ホスト) に読み込む場合があります。この場合、ライブラリに関する 2 つの問題が発生する可能性があります。
コアホストのプログラムで使用される共有ライブラリが dbx ホストのライブラリと異なる場合があります。ライブラリに関して正しいスタックトレースを取得するには、dbx ホストでもオリジナルのライブラリを利用できなくてはいけません。
dbx は、システム上の実行時リンカーとスレッドのライブラリについて実装詳細をわかりやすくするために、/usr/lib に配置されているライブラリを使用します。また、dbx が実行時リンカーのデータ構造とスレッドのデータ構造を理解できるように、コアホストからそれらのシステムライブラリを提供する必要性が出てくることもあります。
ユーザーライブラリとシステムライブラリは、パッチや主要な Solaris オペレーティング環境のアップグレードで変更できるため、収集したコアファイルで dbx を実行する前にパッチをインストールした場合など、この問題が同一ホストでも発生する可能性があります。
dbx は、一致しないコアファイルを読み込むと、次のエラーメッセージを 1 つ以上表示することがあります。
dbx: core file read error: address 0xff3dd1bc not available dbx: warning: could not initialize librtld_db.so.1 -- trying libDP_rtld_db.so dbx: cannot get thread info for 1 -- generic libthread_db.so error dbx: attempt to fetch registers failed - stack corrupted dbx: read of registers from (0xff363430) failed -- debugger service failed
たとえば、コアホストのルートパーティションが NFS を介してエクスポートされており、dbx ホストマシンの /net/core-host/ からアクセスできると想定した場合、次のコマンドを使用して、プログラム prog とコアファイル prog.core をデバッグのために読み込みます。
(dbx) dbxenv core_lo_pathmap on (dbx) pathmap /usr /net/core-host/usr (dbx) pathmap /appstuff /net/core-host/appstuff (dbx) debug prog prog.core
コアホストのルートパーティションをエクスポートしていない場合、手動でライブラリをコピーする必要があります。シンボリックリンクを再作成する必要はありません (たとえば、libc.so から libc.so.1 へのリンクを作成する必要はありません。ただし、libc.so.1 が利用可能である必要があります)。
一致しないコアファイルをデバッグする際に、次の点に注意してください。
pathmap コマンドは '/' のパスマップを認識しないため、次のコマンドを使用できません。
pathmap / /net/core-host
pathmap コマンドの単一引数モードは、ロードオブジェクトのパス名を使用すると機能しません。そのため、2 つの引数をとる form-path to-path モードを使用してください。
dbx ホストがコアホストと同一のバージョンまたはコアホストより最近のバージョンの Solaris オペレーティング環境を有している場合、コアファイルのデバッグが良好に機能する傾向にあります。ただし、これは必須ではありません。
必要となるシステムライブラリを次に示します。
実行時リンカーの場合 :
/usr/lib/ld.so.1
/usr/lib/librtld_db.so.1
/usr/lib/64/ld.so.1
/usr/lib/64/librtld_db.so.1
スレッドライブラリ用 (使用している libthread の実装によって異なる) :
/usr/lib/libthread_db.so.1
/usr/lib/64/libthread_db.so.1
64 ビットバージョンの xxx _db.so ライブラリが必要になるのは、dbx を 64 ビット対応バージョンの Solaris OS で実行している場合です。これらのシステムライブラリはターゲットプログラムではなく dbx の一部として読み込まれて使用されるためです。
ld.so.1 ライブラリは、libc.so などのライブラリのコアファイルイメージの一部であるため、コアファイルを作成したプログラムに一致する 32 ビットまたは 64 ビットの ld.so.1 ライブラリが必要です。
スレッド化されたプログラムからコアファイルを調べていて、および where コマンドがスタックを表示しない場合、 lwp コマンドを使用してみてください。次に例を示します。
(dbx) where current thread: t@0 [1] 0x0(), at 0xffffffff (dbx) lwps o>l@1 signal SIGSEGV in _sigfillset() (dbx) lwp l@1 (dbx) where =>[1] _sigfillset(), line 2 in "lo.c" [2] _liblwp_init(0xff36291c, 0xff2f9740, ... [3] _init(0x0, 0xff3e2658, 0x1, ... ...
lwp コマンドの -setfp および -resetfp オプションは、LWP のフレームポインタ (fp) が壊れているときに便利です。これらのオプションは、assign $fp=... が利用できないコアファイルのデバッグ時に機能します。
スレッドスタックの欠如は、thread_db.so.1 に問題があることを示している場合があります。そのため、コアホストから正しい libthread_db.so.1 ライブラリをコピーしてください。
|