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

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

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

オペレーティング・システムには、オペレーティング・システムの詳細を取得するために使用できるコマンドが用意されています。

• カーネル・バージョン: これは、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 -versionコマンドを使用して、Java SEのバージョン文字列を取得します。

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

jcmd <process ID for the Java process> VM.command_line

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

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

  • LD_LIBRARY_PATH

  • LD_PRELOAD

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

  • OS

  • PROCESSOR_IDENTIFIER

  • _ALT_JAVA_HOME_DIR

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

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

次のリストでは、Linuxでコア・ファイルが生成されない可能性がある理由を示します:

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

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

• 現在のディレクトリに十分な空き領域がありません。

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

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

• プロセスが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コマンド行オプションを使用することで、致命的エラーの状態ではユーザーが介入するまで待つようにプロセスを強制するのが適切である可能性があります。
• クラッシュ・ダンプの強制:

  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コマンド行ユーティリティを使用できます。

  Windowsでは-XX:+ShowMessageBoxOnErrorコマン行オプションを使用することもできます。致命的エラーが発生すると、そのプロセスはメッセージ・ボックスを表示し、ユーザーからの「yes」または「no」の応答を待ちます。

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