16 バグ・レポートの提出
この章では、バグ・レポートを提出する方法を示します。これには、レポートを提出する前に試すこと、およびレポート用に収集するデータに関する提案が含まれています。
この章の構成は、次のとおりです。
更新リリースに含まれる修正のチェック
各リリースへの定期的にスケジュールされた更新には、そのプラットフォームの初期リリース以降に確認された一連のクリティカルなバグの修正が含まれています。
更新リリースが利用可能になると、Java SEダウンロード・ページにあるデフォルトのダウンロードになります。
このダウンロード・サイトには、そのリリースにおけるバグ修正のリストを示すリリース・ノートへのリンクが含まれています。リストにある各バグは、バグ・データベース内のバグの説明にリンクされています。リリース・ノートには、以前の更新リリースにおける修正のリストも含まれています。問題が発生した場合やバグの疑いがある場合には、診断の初期ステップとして、最新の更新リリースで使用可能な修正のリストをチェックしてください。
ある問題が、すでに修正されたバグと同じものであるか明確でない場合があります。
バグ・レポートの提出の準備
次に、バグ・レポートを提出するための推奨手順を示します。
バグ・レポートを提出する前に、次の推奨事項を検討してください。
問題を報告する前に、問題が発生した環境が、サポートされている構成であることを確認します。Oracle JDK 11の動作保証済システム構成を参照してください。
システム構成のほかに、サポート対象のロケールのリストも確認します。JDK 11でサポートされているロケールを参照してください。
Oracle Solarisの場合は、そのオペレーティング・システム用の推奨パッチ・クラスタを調べて、推奨パッチがインストールされていることを確認します。
バグ・レポート用のデータの収集
次の各項に、コマンドの一覧またはデータを取得するための一般的な推奨手順を示します:
問題の詳細な説明
問題の説明を作成するときは、できるだけ多くの関連情報を含めるようにしてください。
アプリケーション、環境、そして問題が発生した時点につながる最も重要なイベントを記述します。
すでに行ったすべてのトラブルシューティングのステップと結果を報告します
複雑なアプリケーション環境でしか問題を再現できない場合があります。その場合は、ログ、コア・ファイル、およびその他の関連情報を伴う説明が問題を診断する唯一の手段になる可能性があります。このような状況では、提出者が問題の発生しているシステムでさらなる診断を行ったり、テスト・バイナリを実行したりする意志があるかどうかをその説明で示すようにしてください。
- 問題が自由に再現可能な場合は、その問題を再現するために必要なステップの一覧を示します。
- 問題を小さなテスト・ケースで再現できる場合は、そのテスト・ケースと、そのテスト・ケースをコンパイルして実行するためのコマンドを含めます。
- テスト・ケースまたは問題にサード・パーティのコード(商用またはオープン・ソースのライブラリやパッケージなど)が必要な場合は、そのライブラリの場所と入手方法についての詳細を提供します。
ハードウェアの詳細
致命的なエラーが発生すると、エラー・ログにハードウェアの詳細が保存されます。
特定のハードウェア構成でのみバグが発生したり再現できたりすることがあります。致命的なエラーが発生した場合は、エラー・ログにハードウェアの詳細が含まれている可能性があります。エラー・ログを入手できない場合は、マシンのプロセッサの番号と種類、クロック速度、および該当する場合かつ既知の場合は、そのプロセッサの機能に関するいくつかの詳細をバグ・レポートにまとめます。たとえばIntelプロセッサの場合、ハイパースレッディングが使用可能であることがそれに該当します。
オペレーティング・システムの詳細
オペレーティング・システムの詳細を取得するために使用できるコマンド。
Oracle Solarisオペレーティング・システムでは、showrev -a
コマンドはオペレーティング・システムのバージョンおよびパッチ情報を出力します。
Linuxでは、使用されているディストリビューションとバージョンを知ることが重要です。/etc/*release
ファイルがリリース情報を示している場合がありますが、コンポーネントとパッケージは個別にアップグレードできるため、必ずしもそれが信頼できる構成を示しているとはかぎりません。そのため、*release
ファイルからの情報に加えて、次の情報も収集してください。
- カーネルのバージョン。これは
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
コマンドを使用して、Java SEのバージョン文字列を取得します。
同じマシン上にJava SEのバージョンが複数インストールされている可能性があります。したがって、失敗したアプリケーションで使用されるjava
コマンドのバージョンを使用してください。これは、ユーザーのPATH
環境変数に含まれるデフォルトのjava
コマンドとは異なる可能性が非常に高くなります。
コマンド行オプション
バグ・レポートに致命的エラー・ログが含まれていない場合は、コマンド行全体とそのすべてのオプションを文書化することが重要です。これには、ヒープ設定を指定するオプション(-Xmx
オプションなど)やHotSpot固有のオプションを指定する-XX
オプションが含まれます。
問題を自由に再現でき、JVMの標準出力(stdout)を読み取ることができる場合は、-XX:+PrintCommandLineFlags
オプションを追加して、アプリケーションで使用されるコマンド行オプションの完全なリストを取得できます。このオプションは、次回JVMを再起動したときにアクティブになります。
次のようにjcmd
コマンドを実行して、実行中のVMのコマンド行オプションを取得することもできます。
jcmd <process ID for the Java process> VM.command_line
また、実行中のJVMのフラグは、jcmd
を使用して変更できます。VM.set_flag
コマンドを参照してください。
環境変数
環境変数の設定が原因で問題が発生する場合があります。バグ・レポートの作成時に、次のJava環境変数の値(設定されている場合)を記入してください。
-
JAVA_TOOL_OPTIONS
-
_JAVA_OPTIONS
-
CLASSPATH
-
JAVA_COMPILER
-
PATH
-
USERNAME
ノート:
障害が発生したアプリケーションのコンテキストから環境変数の値を取得する必要があります。さらに、1つ以上の構成ファイルで、障害が発生したアプリケーションに対してこれらの環境変数の値を設定できます。また、次のオペレーティング・システム固有の環境変数も収集してください。
致命的エラー・ログ
致命的エラーが発生すると、エラー・ログが作成されます。「致命的エラー・ログ」を参照してください。
このエラー・ログには、致命的エラーの発生時に得られた情報(バージョンや環境の情報、クラッシュを引き起こしたスレッドの詳細など)が含まれています。
致命的エラー・ログが生成される場合は、必ずそれをバグ・レポートに含めるか、サポート・コール時に報告してください。
コア・ダンプおよびクラッシュ・ダンプ
報告された問題が原因でコア・ファイルまたはクラッシュ・ダンプが作成された場合は、それをバグ、サイズ許可とともに含めます。
Linuxコア・ファイルまたはWindowsクラッシュ・ダンプには、コアまたはダンプが作成された時点のアプリケーションまたはオペレーティング・システムのメモリー状態が含まれます。システムの構成によっては、クラッシュが発生したときにコア・ダンプまたはクラッシュ・ダンプが自動的に作成される場合があります。システム管理者に問い合せて、コア・ファイルが自動的に生成されるかどうか、およびどこに生成されるかを判断してください。
ハングアップ・プロセスの場合、ダンプを生成する手順については、「コア・ダンプの収集」を参照してください。
ログおよびトレース
ログまたはトレース出力が問題の原因を迅速に特定するのに役立つ可能性があります。
たとえば、パフォーマンスの問題の場合、-verbose:gc
オプションの出力が問題の診断に役立つ可能性があります。このオプションは、ガベージ・コレクタからの出力を有効にします。
それ以外の場合は、Javaフライト・レコーダおよびJDK Mission Controlを使用して、問題に至るまでの期間の統計情報を取得できます。
VMのデッドロックまたはハングの場合は、スレッド・スタックが問題の診断に役立つ可能性があります。スレッド・スタックを取得するには、Oracle SolarisおよびLinuxでは[Ctrl]+[\]、Windowsでは[Ctrl]+[Break]
を押します。または、jcmd
コマンドでThread.dump_to_file
オプションを使用します。
通常は、関連のあるすべてのログ、トレース、およびその他の出力をバグ・レポートまたはサポート・コール時に提供します。
コア・ダンプの収集
コア・ダンプまたはクラッシュ・ダンプとは、プロセスのメモリー・スナップショットです。
コア・ダンプは、致命的エラーまたは処理できないエラーの発生時にオペレーティング・システムによって自動的に作成されることがあります。また、コア・ダンプはシステム提供のコマンド行ユーティリティを使用して強制的に取得することもできます。ハングアップしているように見えるプロセスを診断する際にコア・ダンプが役立つ場合があります。つまり、コア・ダンプによってハングアップの原因に関する情報が明らかになることがあります。
次の項では、コア・ダンプの収集シナリオについて説明します。
Oracle Solarisでのコア・ダンプの収集
デフォルトでは、コア・ダンプはプロセスの現在の作業ディレクトリに作成されます。コア・ダンプ・ファイルの名前はcore
です。ユーザーは、コア・ファイル管理ユーティリティcoreadm
を使用すると、そのコア・ダンプの場所と名前を構成できます。この手順については、coreadm
ユーティリティのマニュアル・ページに詳しく説明されています。
ulimit
ユーティリティは、現在のシェルとその子孫で利用できるシステム・リソースへの制限を設定または取得するために使用されます。コア・ファイルのサイズ制限をチェックまたは設定するには、ulimit -c
コマンドを使用します。その制限が必ずunlimited
に設定されるようにしてください。そうしないと、コア・ファイルが切り詰められる可能性があります。
ノート:
ulimit
はBashシェルの組込みコマンドです。Cシェルでは、limit
コマンドを使用してください。
VMまたはアプリケーションの起動に使用されるスクリプトがコア・ダンプの作成を無効にしないようにしてください。
gcore
ユーティリティを使用すると、実行中のプロセスのコア・イメージを取得できます。このユーティリティは、コア・ダンプを強制的に作成させるプロセスのプロセスID (pid)を受け入れます。
マシン上で実行されているJavaプロセスのリストを取得するには、次のいずれかのコマンドを使用できます。
次は、Oracle Solarisでコア・ダンプを収集するための2つの方法です。
-
Oracle SolarisでのShowMessageBoxOnErrorオプション:
Javaプロセスは、
-XX:+ShowMessageBoxOnError
コマンド行オプションを使って起動できます。致命的エラーが発生すると、そのプロセスは標準エラーにメッセージを出力し、標準入力からの「yes
」または「no
」の応答を待ちます。 -
trussユーティリティによるプロセスの中断:
-XX:+ShowMessageBoxOnError
オプションを指定できない場合は、truss
ユーティリティを使用できる可能性があります。このOracle Solarisオペレーティング・システムのユーティリティは、システム・コールおよびシグナルをトレースするために使用されます。このユーティリティを使用すると、特定の関数またはシステム・コールに達した時点でプロセスを中断できます。次の例のコマンドは、
truss
ユーティリティを使用して、exit
システム・コールが実行される(つまり、プロセスが終了しようとしている)ときにプロセスを中断する方法を示しています。$ truss -t \!all -s \!all -T exit -p pid
プロセスが
exit
を呼び出すと、そのプロセスが中断されます。この時点で、デバッガをプロセスに接続することも、gcore
を呼び出してコア・ダンプを強制することもできます。
Linuxでのコア・ダンプの収集
デフォルトでは、コア・ダンプはプロセスの現在の作業ディレクトリに作成されます。コア・ダンプ・ファイルの名前はcore.pid
で、pid
はクラッシュしたJavaプロセスのプロセスIDです。
すべてのシステムがコア・ファイルの作成を許可するように構成されているわけではありません。ulimit
ユーティリティは、現在のシェルとその子孫で利用できるシステム・リソースへの制限を設定または取得するために使用されます。コア・ファイルのサイズ制限をチェックまたは設定するには、ulimit -c
コマンドを使用します。その制限が必ずunlimited
に設定されるようにしてください。そうしないと、コア・ファイルが切り詰められたり生成されない可能性があります。
ノート:
ulimit
はBashシェルの組込みコマンドです。Cシェルでは、limit
コマンドを使用してください。
VMまたはアプリケーションの起動に使用されるスクリプトがコア・ダンプの作成を無効にしないようにしてください。
gcore
コマンドをgdb
(GNUデバッガ)インタフェースで使用すると、実行中のプロセスのコア・イメージを取得できます。このユーティリティは、コア・ダンプを強制的に作成させるプロセスのpid
を受け入れます。
マシン上で実行されているJavaプロセスのリストを取得するには、次のいずれかのコマンドを使用できます。
jcmd
ps -ef | grep java
pgrep java
ShowMessageBoxOnError
オプションを使用して、Linuxでコア・ダンプを収集できます。-XX:+ShowMessageBoxOnError
コマンド行オプションを使用してJavaプロセスを起動します。致命的エラーが発生すると、そのプロセスは標準エラーにメッセージを出力し、標準入力からの「yes
」または「no
」の応答を待ちます。
コア・ファイルを取得しない理由
次のリストでは、Linuxでコア・ファイルが生成されない可能性がある理由を示します:
-
アプリケーション・ユーザーに、そのプロセスの現在の作業ディレクトリへの書込み権がありません。
-
アプリケーション・ユーザーには現在の作業ディレクトリへの書込み権がありますが、読取り専用の権限を持つ
core
という名前のファイルがすでに存在しています。 -
現在のディレクトリに十分な空き領域がありません。
-
現在のディレクトリに、
core
という名前のサブディレクトリがあります。 -
現在の作業ディレクトリがリモートです。ネットワーク・ファイル・システム(NFS)にマップされている可能性があり、コア・ダンプが作成されようとしているときにNFSが失敗しました。
-
Oracle Solarisオペレーティング・システムのみ:
coreadm
ツールを使用してコア・ファイルのディレクトリと名前が構成されましたが、構成されたディレクトリに前述の1つ以上の理由が当てはまります。 -
プロセスが
setuid
プログラムを実行しているため、オペレーティング・システムは、明示的に構成されないかぎり、コアをダンプしません。 -
Java固有: プロセスが
SIGSEGV
またはSIGILL
を受信してもコア・ファイルが生成されなかった場合、プロセスがそれを処理した可能性があります。たとえば、HotSpot VMはSIGSEGV
シグナルを、正当な目的(NullPointerException
のスローや最適化解除など)のために使用します。Java VMによってシグナルが処理されないのは、現在の命令(PC)がJava VM生成コードから外れる場合だけです。これらが、HotSpotでコアがダンプされる唯一の場合になります。 -
Java固有: VMの作成に、JNI呼び出しAPIが使用されました。標準のJavaランチャは使用されませんでした。カスタムJavaランチャ・プログラムが、シグナルを消費してその処理をすませ、ログ・エントリを暗黙のうちに生成しました。この状況は、特定のアプリケーション・サーバーやWebサーバーで発生しました。これらのJava VM埋め込みプログラムは、異常終了後にシステムの再起動(フェイルオーバー)を透過的に試行します。この場合、コア・ダンプが生成されないという事実は、機能であってバグではありません。
Windowsでのクラッシュ・ダンプの収集
Windowsオペレーティング・システムでは、ワトソン博士ログ・ファイル、ユーザー・ミニダンプおよびワトソン博士フル・ダンプの3種類のクラッシュ・ダンプがあります。
-
ワトソン博士のログ・ファイル。これは、障害時のスタック・トレースとその他のいくつかの詳細を含むテキスト・エラー・ログ・ファイルです。
-
ユーザーのミニダンプ。これは部分的なコア・ダンプと見なされます。このダンプにはプロセスの有用なメモリー・ページがすべて含まれているわけではないため、完全なコア・ダンプではありません。
-
ワトソン博士の完全ダンプ。これは、UNIXコア・ダンプと同等のものです。このダンプには、コード・ページを除くプロセスのほとんどのメモリー・ページが含まれています。
Windowsで予期しない例外が発生した場合、実行されるアクションは次のレジストリ・キーの2つの値によって異なります。
\\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug
それらの2つの値には、Debugger
およびAuto
という名前が付いています。Auto
値は、アプリケーション・エラーが発生したときに、Debugger
エントリの値で指定されたデバッガが自動的に起動するかどうかを示します。
-
Auto
値が0
の場合は、アプリケーション・エラーが発生したときにシステムがメッセージ・ボックスを表示してユーザーに知らせることを示します。 -
Auto
値が1
の場合は、デバッガが自動的に起動することを示します。
Debugger
の値は、プログラム・エラーのデバッグに使用されるデバッガ・コマンドです。
Windowsでは、プログラム・エラーが発生すると、Auto
値を調べて、その値が0
,の場合に、Debugger
値に含まれるコマンドを実行します。Debugger
の値が有効なコマンドである場合は、「OK」と「キャンセル」の2つのボタンを含むメッセージ・ボックスが作成されます。ユーザーが「OK」をクリックすると、プログラムが終了します。ユーザーが「キャンセル」をクリックすると、指定されたデバッガが開始されます。Auto
エントリの値が1
に設定され、Debugger
エントリの値が有効なデバッガを表すコマンドを指定している場合、システムはそのデバッガを自動的に起動し、メッセージ・ボックスを生成しません。
次は、Windowsでクラッシュ・ダンプを収集するための2つの方法です。