コアファイルおよびクラッシュダンプは、プロセスまたはアプリケーションが異常終了したときに生成されます。これらのファイルを分析することが、問題の原因特定に役立ちます。
この節では、次の内容について説明します。
コアファイルを分析するため、Directory Proxy Server プロセスに関係付けられたすべてのライブラリおよびバイナリを取得します。サーバーがクラッシュしたときに Directory Proxy Server がコアファイルを生成できるように、システムを設定します。コアファイルの生成の詳細については、「コアファイルの生成」を参照してください。
pkg_app スクリプトを使用してライブラリを収集します。pkg_app スクリプトは、実行可能ファイルとそのすべての共用ライブラリを、圧縮された 1 つの tar ファイルにパッケージ化します。アプリケーションのプロセス ID、および開くコアファイルの名前 (必要な場合) を指定します。pkg_app スクリプトの詳細については、「Solaris での pkg_app スクリプトの使用」を参照してください。
superuser として、pkg_app スクリプトを次のように実行します。
# pkg_app pid core-file |
コアファイルを指定せずに pkg_app スクリプトを実行することもできます。これにより、スクリプトの出力サイズが小さくなります。あとで、変数をコアファイルの正しい場所に設定する必要があります。
コアファイルを取得したあとで、このファイルに対して jstack および jpmap Java ツールを実行します。
次のように jstack ユーティリティーを実行します。
# jstack process-ID |
次に、jstack ユーティリティーの出力例を示します。
# jstack 8393 Attaching to process ID 8393, please wait... Debugger attached successfully. Server compiler detected. JVM version is 1.5.0_03-b07 Thread t@1: (state = BLOCKED) Thread t@42: (state = IN_NATIVE) - sun.nio.ch.ServerSocketChannelImpl.accept0(java.io.FileDescriptor, \ java.io.FileDescriptor, java.net.InetSocketAddress[]) (Interpreted frame) - sun.nio.ch.ServerSocketChannelImpl.accept0(java.io.FileDescriptor, \ java.io.FileDescriptor, java.net.InetSocketAddress[]) (Interpreted frame) - sun.nio.ch.ServerSocketChannelImpl.accept() @bci=130, line=145 \ (Interpreted frame) - com.sun.directory.proxy.extensions.ExtendedTCPClientListener.run() \ @bci=267, line=190 (Interpreted frame) Thread t@41: (state = IN_NATIVE) - sun.nio.ch.ServerSocketChannelImpl.accept0(java.io.FileDescriptor, \ java.io.FileDescriptor, java.net.InetSocketAddress[]) (Interpreted frame) - sun.nio.ch.ServerSocketChannelImpl.accept0(java.io.FileDescriptor, \ java.io.FileDescriptor, java.net.InetSocketAddress[]) (Interpreted frame) - sun.nio.ch.ServerSocketChannelImpl.accept() @bci=130, line=145 \ (Interpreted frame) - com.sun.directory.proxy.extensions.ExtendedTCPClientListener.run() \ @bci=267, line=190 (Interpreted frame) |
コアファイルを取得したあとで、このファイルに対して pstack および pmap Solaris ユーティリティーを実行します。
次のように pstack ユーティリティーを実行します。
# pstack core-file > /tmp/pstack.txt |
次に、pstack ユーティリティーの出力例を示します。
core '/var/core/core_dps-dr-zone1_ldapfwd_0_0_1156942096_3167' of 3167: ./ldapfwd -t /var/opt/mps/serverroot/dps-dps-dr-zone1/etc/tailor.txt ----------------- lwp# 1 / thread# 1 -------------------- fedc0b6c __pollsys (ffbff680, 2, ffbff610, 0, 0, 1770) + 8 fed5cea8 poll (ffbff680, 2, 1770, 10624c00, 0, 0) + 7c ff19c610 _pr_poll_with_poll (1770, ffbff680, 927c0, ffbff91c, 2, 1) + 42c 00039504 __1cLCAI_LF_CmgrDrun6F_v_ (75, 115d74, 11202c, 2, 88c00, 116510) + 1a8 00062070 ldapfwdMain (0, ffbffa84, c, 9952c, feb60740, feb60780) + 1c 0002f968 _start (0, 0, 0, 0, 0, 0) + 108 ----------------- lwp# 3 / thread# 3 -------------------- fedc0b6c __pollsys (fea19b70, 3, fea19b00, 0, 0, 3e8) + 8 fed5cea8 poll (fea19b70, 3, 3e8, 10624c00, 0, 0) + 7c ff19c610 _pr_poll_with_poll (3e8, fea19b70, 186a0, fea19e8c, 3, 2) + 42c 0005de38 __1cIidarPollEwait6MI_i_ (fea19e6c, 186a0, 16e360, 1, 0, 1) + 20 000639ec __1cJHeartbeatJheartbeat6Fpv_1_ (158f40, 1, 14da70, faa36, 16e360, faa5d) + 114 fedbfd9c _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 136734 / thread# 136734 -------------------- fedbfe40 __lwp_park (0, 0, 116710, 0, 0, 1) + 14 00076548 __1cMCAI_LF_MutexHacquire6M_v_ (116708, fd2bc, 0, 46, fea24800, 1000) + 34 00076158 __1cPCAI_LF_RefCountGAddRef6M_v_ (116708, 156510, 2400, 26dc, 11667c, 800) + 24 0006ddb0 __1cVCAI_LF_ReferralServer2t5B6MpnPCAI_LF_ConnPair_pnVCAI_LF_RequestMessage_pnNCAI_LF_Server _ipcibbi_v_ (197198, fe7790d8, 1541c0, 156510, 185, 1565b8) + 50 00046324 __1cPCAI_LF_ConnPairYstart_referral_operation6MipCpnNCAI_LF_Server_i_i_ (fe7790d8, 1, 1565b8 , 156510, 1, 197198) + 26c 0004f2a0 __1cPCAI_LF_ConnPairLsend_result6MrnOCAI_LF_Message_rnVCAI_LF_RequestMessage__v_ (fe7790d8, 156eb8, 1541c0, 2400, 0, 0) + 354 00044758 __1cPCAI_LF_ConnPairOinner_activity6MpnOCAI_LF_Message__v_ (fe7790d8, 156eb8, 11202c, f4f27, fe7790f8, 1) + 114c 00045c24 __1cPCAI_LF_ConnPairDrun6M_v_ (fe7797c8, 198383, 170c78, fe7790d8, fe779e54, fe779740) + 6cc 00046cd0 CAI_LF_StartFunction (157500, 11202c, 1, 0, 46ab4, 1) + 21c fedbfd9c _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 136735 / thread# 136735 -------------------- fedc0b6c __pollsys (fe9e8d98, 3, fe9e8d28, 0, 0, 1d4c0) + 8 fed5cea8 poll (fe9e8d98, 3, 1d4c0, 10624c00, 0, 0) + 7c ff19c610 _pr_poll_with_poll (1d4c0, fe9e8d98, b71b00, fe9e9e74, 3, 2) + 42c 0005de38 __1cIidarPollEwait6MI_i_ (fe9e9e54, b71b00, 1, f4f27, fe9e90f8, 12d8d0) + 20 00045cbc __1cPCAI_LF_ConnPairDrun6M_v_ (fe9e97c8, 17bb43, 130ff8, fe9e90d8, fe9e9e54, fe9e9740) + 764 00046cd0 CAI_LF_StartFunction (157500, 11202c, 1, 0, 46ab4, 1) + 21c fedbfd9c _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 136738 / thread# 136738 -------------------- fedc0b6c __pollsys (fe9a8d98, 3, fe9a8d28, 0, 0, 1d4c0) + 8 fed5cea8 poll (fe9a8d98, 3, 1d4c0, 10624c00, 0, 0) + 7c ff19c610 _pr_poll_with_poll (1d4c0, fe9a8d98, b71b00, fe9a9e74, 3, 2) + 42c 0005de38 __1cIidarPollEwait6MI_i_ (fe9a9e54, b71b00, 1, f4f27, fe9a90f8, 0) + 20 00045cbc __1cPCAI_LF_ConnPairDrun6M_v_ (fe9a97c8, 198123, 130fd8, fe9a90d8, fe9a9e54, fe9a9740) + 764 00046cd0 CAI_LF_StartFunction (157500, 11202c, 1, 0, 46ab4, 1) + 21c fedbfd9c _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 136788 / thread# 136788 -------------------- 00197d68 ???????? (116708, 1, 156510, 0, 0, 1000) 0006dee4 __1cVCAI_LF_ReferralServer2T6M_v_ (155780, 1000, fedecbc0, fea25c00, fe779780, 0) + 34 000707c4 __SLIP.DELETER__A (155780, 1, 4, a6c, 1, 2400) + 4 00046a94 CAI_LF_ReferralStartFunction (155780, fe6da000, 0, 0, 46a64, 1) + 30 fedbfd9c _lwp_start (0, 0, 0, 0, 0, 0) |
pstack コマンドの代わりに mdb または adb コマンドを使用してもコアのスタックを表示できます。mdb コマンドはモジュラーデバッガであり、adb コマンドは Solaris に含まれる汎用デバッガです。次のように 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 を含まないスレッドを検索して、スタックを分析します。
Solaris では、Solaris dbx シンボリックデバッガも使用できます。これは、http://sun.com/ から無料で入手可能な開発者用のツールです。dbx ツールを使用すると、シンボリックデバッグを実行できます。このツールには操作可能な変数が含まれます。次に、dbx デバッガの出力例を示します。
current thread: t@2482121 =>[1] 0x0(0x156138, 0x0, 0xff000000, 0xfedefad4, 0x2, 0x2), at 0xffffffffffffffff [2] CAI_LF_RefCount::Release(0x116708, 0x1, 0x156138, 0x0, 0x0, 0x1000), at 0x7629c [3] CAI_LF_ReferralServer::~CAI_LF_ReferralServer(0x241270, 0x1000, 0xfedecbc0, 0xfe097c00, 0xfe8d9780, 0x0), at 0x6dee4 [4] __SLIP.DELETER__A(0x241270, 0x1, 0x4, 0xa6c, 0x1, 0x2400), at 0x707c4 [5] CAI_LF_ReferralStartFunction(0x241270, 0xfe81a000, 0x0, 0x0, 0x46a64, 0x1), at 0x46a94 |
Linux では、Solaris の pstack ユーティリティーの代わりに lsstack または pstack コマンドを使用します。次のように lsstack コマンドを実行します。
# lsstack /tmp/core-file |
GNU プロジェクトデバッガ gdb を使用して、クラッシュ時に何が起きたかを確認することもできます。次のようにデバッガを実行します。
# gdb ./ldapfwd /tmp/core-file |
gdb ツールで使用可能な有用なコマンドの詳細については、gdb のマニュアルページを参照してください。
HP-UX では、Linux の場合と同様、GNU プロジェクトデバッガを使用してクラッシュ時に何が起きたかを確認することもできます。次のようにデバッガを実行します。
# gdb ./ldapfwd /tmp/core-file |
gdb ツールで使用可能な有用なコマンドの詳細については、gdb のマニュアルページを参照してください。
Windows では、カーネルおよび NT デバッグ用の UI を提供する WinDbg デバッガを使用できます。このデバッガは、カーネルモードとユーザーモードの両方で動作可能です。Windows のクラッシュダンプファイルに対して、このデバッガを実行します。