致命的なエラーが発生すると、エラー・ログにハードウェアの詳細が保存されます。

オペレーティング・システムの詳細を取得するために使用できるコマンド。

• カーネルのバージョン。これはuname -aコマンドを使って取得できます。
• glibcのバージョン。rpm -q glibcコマンドは、glibcのパッチ・レベルを示します。
• スレッド・ライブラリ。Linuxには、LinuxThreadsおよびNPTLという2つのスレッド・ライブラリがあります。LinuxThreadsライブラリは2.4以前のカーネルで使用され、固定スタックと浮動スタックのバリアントがあります。Native POSIX Thread Library (NPTL)は2.6カーネルで使用されます。一部のLinuxリリース(RHEL3など)には、NPTLの2.4カーネルへのバックポートが含まれています。使用されているスレッド・ライブラリを確認するには、コマンドgetconf GNU_LIBPTHREAD_VERSIONを使用します。getconfコマンドが、その変数が存在しないことを示すエラーを返す場合は、古いカーネルをLinuxThreadsライブラリとともに使用している可能性があります。

Java SEのバージョン文字列は、java -versionコマンドを使用すると取得できます。

バグ・レポートに致命的エラー・ログが含まれていない場合は、コマンド行全体とそのすべてのオプションを文書化することが重要です。これには、ヒープ設定を指定するオプション(たとえば、-mxオプション)や、HotSpot固有のオプションを指定する-XXオプションが含まれます。

環境変数の設定が原因で問題が発生する場合があります。バグ・レポートの作成時に、次のJava環境変数の値(設定されている場合)を記入してください。

• Oracle SolarisおよびLinuxオペレーティング・システムでは、次の環境変数の値を収集します。

  • LD_LIBRARY_PATH

  • LD_PRELOAD

  • SHELL

  • DISPLAY

  • HOSTTYPE

  • OSTYPE

  • ARCH

  • MACHTYPE

• Linuxでは、次の環境変数の値も収集します。

  • LD_ASSUME_KERNEL

  • _JAVA_SR_SIGNUM

• Windowsでは、次の環境変数の値を収集します。

  • OS

  • PROCESSOR_IDENTIFIER

  • _ALT_JAVA_HOME_DIR

致命的エラー・ログは、致命的エラーの発生時に作成されます。

コア・ダンプやクラッシュ・ダンプは、システム・クラッシュまたはハングアップ・プロセスの診断を試みる際に非常に役立つ可能性があります。

問題の説明を作成するときは、できるだけ多くの関連情報を含めるようにしてください。

• 問題が再現可能な場合は、その問題を再現するために必要なステップの一覧を示します。
• 問題を小さなテスト・ケースで再現できる場合は、そのテスト・ケースと、そのテスト・ケースをコンパイルして実行するためのコマンドを含めます。
• テスト・ケースまたは問題にサード・パーティのコード(商用またはオープン・ソースのライブラリやパッケージなど)が必要な場合は、そのライブラリの場所と入手方法についての詳細を提供します。

ログまたはトレース出力が問題の原因を迅速に特定するのに役立つ可能性があります。

すでに行ったすべてのトラブルシューティングのステップと結果を報告します

Oracle Solarisオペレーティング・システムでは、セグメンテーション違反や不正な命令などの処理できないシグナルによってコア・ダンプが作成されます。

• ps -ef | grep java
• pgrep java
• jps

  ノート:

  jpsコマンド行ユーティリティでは、名前の照合(つまり、プロセスのコマンド名の中に「java」がないか検索する)を行わないため、Javaプロセスだけでなく、Java VMの埋込みプロセスも一覧表示できます。

Linuxオペレーティング・システムでは、セグメンテーション違反や不正な命令などの処理できないシグナルによってコア・ダンプが作成されます。

• ps -ef | grep java
• pgrep java
• jps

  ノート:

  jpsコマンド行ユーティリティでは、名前の照合(つまり、プロセスのコマンド名の中に「java」がないか検索する)を行わないため、Javaプロセスだけでなく、Java VMの埋込みプロセスも一覧表示できます。

コア・ファイルが生成されない場合がある理由のリスト。

特に断りがないかぎり、このリストはOracle SolarisとLinuxオペレーティング・システムの両方に関連します。

• ユーザーに、そのプロセスの現在の作業ディレクトリへの書込み権がありません。

• ユーザーには現在の作業ディレクトリへの書込み権がありますが、読取り専用の権限を持つcoreという名前のファイルがすでに存在しています。

• 現在のディレクトリに十分な空き領域がないか、空き領域がまったく残っていません。

• 現在のディレクトリに、coreという名前のサブディレクトリがあります。

• 現在の作業ディレクトリがリモートです。ネットワーク・ファイル・システム(NFS)によってマップされている可能性があり、コア・ダンプが作成されようとしているときにNFSが失敗しました。

• Oracle Solarisオペレーティング・システムのみ: coreadmツールを使用してコア・ファイルのディレクトリと名前が構成されましたが、構成されたディレクトリに前述の1つ以上の理由が当てはまります。

• コア・ファイルのサイズ制限が低すぎます。ulimit -cコマンド(Bashシェル)またはlimit -cコマンド(Cシェル)を使用して、コア・ファイル・サイズの制限をチェックしてください。このコマンドからの出力がunlimitedでない場合、コア・ダンプのファイル・サイズが十分な大きさでない可能性があります。その場合は、切り詰められたコア・ダンプが作成されるか、コア・ダンプがまったく作成されません。また、VMまたはアプリケーションの起動に使用されるスクリプトがコア・ダンプの作成を無効にしないようにしてください。

• プロセスがsetuidプログラムを実行しているため、オペレーティング・システムは、明示的に構成されないかぎり、コアをダンプしません。

• Java固有: プロセスがSIGSEGVまたはSIGILLを受信してもコアがダンプされなかった場合、プロセスがそれを処理した可能性があります。たとえば、HotSpot VMはSIGSEGVシグナルを、正当な目的(NullPointerExceptionのスローや最適化解除など)のために使用します。Java VMによってシグナルが処理されないのは、現在の命令(PC)がJava VM生成コードから外れる場合だけです。これらが、HotSpotでコアがダンプされる唯一の場合になります。

• Java固有: VMの作成に、JNI呼び出しAPIが使用されました。標準のJavaランチャは使用されませんでした。カスタムJavaランチャ・プログラムが、シグナルを消費してその処理をすませ、ログ・エントリを暗黙のうちに生成しました。この状況は、特定のアプリケーション・サーバーやWebサーバーで発生しました。これらのJava VM埋め込みプログラムは、異常終了後にシステムの再起動(フェイルオーバー)を透過的に試行します。この場合、コア・ダンプが生成されないという事実は、機能であってバグではありません。

Windowsオペレーティング・システムでは、ワトソン博士ログ・ファイル、ユーザー・ミニダンプおよびワトソン博士フル・ダンプの3種類のクラッシュ・ダンプがあります。

\\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug

• ワトソン博士の構成:

  ワトソン博士のデバッガは、クラッシュ・ダンプ・ファイルの作成に使用されます。デフォルトでは、ワトソン博士のデバッガ(drwtsn32.exe)はWindowsシステム・フォルダ(%SystemRoot%\System32)にインストールされます。

  ワトソン博士をポストモーテム・デバッガとしてインストールするには、次のコマンドを実行します。

  drwtsn32 -i
  

  クラッシュ・ダンプ・ファイルの名前と場所を構成するには、オプションを付けずにdrwtsn32を実行します。

  ワトソン博士のGUIウィンドウで、「クラッシュ・ダンプ・ファイルの作成」チェック・ボックスが選択されていること、およびクラッシュ・ダンプ・ファイル・パスとログ・ファイル・パスがそれぞれのテキスト・フィールドに構成されていることを確認します。

  レジストリを使用すると、フル・ダンプを作成するようにワトソン博士を構成できます。レジストリ・キーを次の例に示します。

  System Key: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DrWatson]
  Entry Name: CreateCrashDump
  Value: (0 = disabled, 1 = enabled)
  

  ノート:

  アプリケーションが例外を処理する場合は、レジストリで構成されたデバッガは呼び出されません。その場合は、-XX:+ShowMessageBoxOnErrorコマンド行オプションを使用することで、致命的エラーの状態ではユーザーが介入するまで待つようにプロセスを強制するのが適切である可能性があります。
• クラッシュ・ダンプの強制:

  Windowsオペレーティング・システムでは、userdumpコマンド行ユーティリティを使って実行中のプロセスのDr. Watsonダンプを強制できます。userdumpユーティリティはWindowsに同梱されていません。OEM Support Toolsパッケージのコンポーネントとして提供されています。

  クラッシュ・ダンプを強制する別の方法は、windbgデバッガを使用することです。windbgを使用することの主な利点は、非侵入的な方法(つまり読取り専用)でプロセスに接続できることです。通常、Windowsはクラッシュ・ダンプの取得後にプロセスを終了させますが、非侵入型の接続ではクラッシュ・ダンプの取得後もプロセスを続行できます。デバッガを接続するには、「Attach to Process」オプションを選択し、「Noninvasive」チェック・ボックスを選択します。

  デバッガが接続されたら、次の例に示されたコマンドを使用してクラッシュ・ダンプを取得できます。

  .dump /f crash.dmp
  

  windbgデバッガは、Debugging Tools for Windowsのダウンロードに含まれています。

  このダウンロードに含まれる追加のdumpchk.exeユーティリティは、メモリー・ダンプ・ファイルが正しく作成されたことを検証できます。

  userdump.exeとwindbgのどちらにも、プロセスのpidが必要です。userdump -pコマンドは、すべてのプロセスのプロセスとプログラムを一覧表示します。これは、アプリケーションがjava.exeランチャで起動されることがわかっている場合に役立ちます。ただし、カスタム・ランチャが使用される場合(埋込みVM)、プロセスの認識が困難である可能性があります。その場合は、JavaプロセスのPIDのみを一覧表示するjpsコマンド行ユーティリティを使用できます。

  Oracle SolarisおよびLinuxオペレーティング・システムと同様に、Windowsでも-XX:+ShowMessageBoxOnErrorコマンド行オプションを使用できます。致命的エラーが発生すると、プロセスはメッセージ・ボックスを表示し、ユーザーからのyesまたはnoの応答を待ちます。

  「はい」または「いいえ」をクリックする前に、userdump.exeユーティリティを使用して、そのJavaプロセスのワトソン博士のダンプを生成できます。このユーティリティは、プロセスがハングアップしているように見える場合にも使用できます。