コアファイルを取得したあとで、このファイルに対して pstack および pmap Solaris ユーティリティーを実行します。pmap ユーティリティーは、仮想アドレスのリストを含むプロセスマップを表示します。仮想アドレスは、動的ライブラリの読み込み先であるとともに、変数が宣言される場所でもあります。pstack ユーティリティーにより、プロセススタックが表示されます。これは、プロセス内のスレッドごとに、プロセスの終了時または pstack コマンドの実行時にスレッドが実行していた命令のスタックを示します。
これらのユーティリティーは、ns-slapd バイナリ root-dir/bin/slapd/server を含むディレクトリから実行する必要があります。次に示すようにユーティリティーを実行します。
# pstack core-file |
# pmap core-file |
pstack ユーティリティーの結果がほぼ空である場合は、すべての出力行が次のようになります。
0002c3cc ???????? (1354ea0, f3400, 1354ea0, 868, 2fc, 1353ff8) |
pstack の出力がこのような場合は、ns-slapd バイナリディレクトリからこのユーティリティーを実行していることを確認してください。ns-slapd バイナリディレクトリからこのユーティリティーを実行していなかった場合は、このディレクトリに移動してユーティリティーを再度実行します。
pstack コマンドの代わりに mdb コマンドを使用してもコアのスタックを確認できます。次のように mdb コマンドを実行します。
# mdb $path-to-executable $path-to-core $C to show the core stack $q to quit |
mdb および pstack コマンドの出力から、クラッシュ時のプロセススタックに関する有用な情報を入手できます。mdb $C コマンドの出力から、クラッシュを引き起こしたスレッドを特定できます。
Solaris 8 および 9 では、多くの場合、pstack 出力の最初のスレッドにクラッシュの原因となったスレッドが含まれます。Solaris 10 では、mdb を使用してクラッシュの原因となったスレッドを特定します。pstack コマンドを使用する場合は、lwp-park、poll、および pollsys を含まないスレッドを検索して、スタックを分析します。
たとえば、プラグイン関数の呼び出し時に、次のコアプロセススタックが発生します。
core '../../../slapd-psvmrr3-27/logs/core' of 18301: ./ns-slapd \ -D /opt/iplanet/servers/slapd-psvmrr3-27 -i /opt/iplanet/se ----------------- lwp# 13 / thread# 25 -------------------- ff2b3148 strlen (0, fde599fb, 0, fbed1, 706d2d75, fde488a8) + 1c ff307ef8 sprintf (7fffffff, fde488a0, fde599d8, fde599ec, 706d2d75, fde599fc) \ + 3c fde47cf8 ???????? (1354ea0, 850338, fde59260, e50243, 923098, 302e3800) + f8 fde429cc ???????? (1354ea0, 3, 440298, 154290, 345c10, 154290) + 614 ff164018 plugin_call_exop_plugins (1354ea0, 8462a0, d0c, ff1e7c70, ff202a94, \ 1353ff8) + d0 0002c3cc ???????? (1354ea0, f3400, 1354ea0, 868, 2fc, 1353ff8) 00025e08 ???????? (0, 1353ff8, fdd02a68, f3400, f3000, fbc00) fef47d18 _pt_root (362298, fe003d10, 0, 5, 1, fe401000) + a4 fed5b728 _thread_start (362298, 0, 0, 0, 0, 0) + 40 |
コアから取得したプロセススタックを分析する際は、スレッド中央の操作に注目します。下部のプロセスは分析するには一般的過ぎ、上部のプロセスは限定的過ぎます。スレッド中央のコマンドは Directory Server に固有のものであるため、処理のどの時点で操作が失敗したかを識別する助けになります。上の例では、plugin_call_exop_plugins プロセス呼び出しで、カスタムプラグイン内の外部操作の呼び出し時に問題が発生したことを示しています。
Directory Server 関連の問題の場合は、問題の原因である可能性のもっとも高い関数呼び出しを使って SunSolve で検索し、この関数呼び出しに関連する問題を参照できます。SunSolve には、http://sunsolve.sun.com/ でアクセスできます。
発生している問題に関連する問題が見つかった場合は、それが実行中の Directory Server のバージョンに適用されるか確認します。バージョンの情報を取得するには、次のコマンドを使用します。
# ns-slapd -V |
コアファイルの基本的な分析を行っても問題を特定できない場合は、pkg_app スクリプトを使ってバイナリおよびライブラリを収集し、Sun サポートセンターに連絡してください。