特定のシステム (コアホスト) で作成されたコアファイルを、デバッグのためにそのファイルを別のマシン (dbx ホスト) に読み込む場合があります。この場合、ライブラリに関する 2 つの問題が発生する可能性があります。
コアホスト上のプログラムによって使用される共有ライブラリが、dbx ホスト上のライブラリと同じライブラリでない可能性があります。ライブラリに関する正しいスタックトレースを取得するには、これらの元のライブラリを dbx ホスト上で使用できるようにしてください。
dbx は、/usr/lib 内のシステムライブラリを使用して、システム上の実行時リンカーやスレッドライブラリの実装に関する詳細の理解に役立てます。dbx が実行時リンカーのデータ構造やスレッドのデータ構造を理解できるように、これらのシステムライブラリをコアホストからも提供することが必要になる可能性があります。
ユーザーライブラリやシステムライブラリは、パッチや Oracle 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
一致しないコアファイルをデバッグする際に、次の点に注意してください。
pathmap コマンドは '/' のパスマップを認識しないため、次のコマンドを使用できません。
pathmap / /net/core-host
pathmap コマンドの単一引数モードはロードオブジェクトのパス名では機能しないため、2 つの引数をとる from-path to-path モードを使用してください。
コアファイルのデバッグは、dbx ホストの Oracle 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
xxx_db.so ライブラリはターゲットプログラムの一部としてではなく、dbx の一部としてロードおよび使用されるため、dbx が 64 ビット対応バージョンの Oracle Solaris OS 上で実行されている場合は、これらのシステムライブラリの 64 ビットバージョンが必要です。
ld.so.1 ライブラリは libc.so やその他のライブラリなどのコアファイルイメージの一部であるため、そのコアファイルを作成したプログラムに一致する 32 ビットの ld.so.1 ライブラリまたは 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 ライブラリをコピーしてみることも必要になる場合があります。
たとえば、コアホストのルートパーティションが 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 が使用できることを確認してください。