16 バグ・レポートの提出
バグ・レポートの提出方法に関する指針。これには、レポートを提出する前に試すこと、およびレポート用に収集するデータに関する提案が含まれています。
この章の構成は、次のとおりです。
更新リリースに含まれる修正のチェック
各リリースへの定期的にスケジュールされた更新には、そのプラットフォームの初期リリース以降に確認された一連のクリティカルなバグの修正が含まれています。
更新リリースが利用可能になると、Java SEダウンロード・サイトにあるデフォルトのダウンロードになります。
このダウンロード・サイトには、そのリリースにおけるバグ修正のリストを示すリリース・ノートが含まれています。リストにある各バグは、バグ・データベース内のバグの説明にリンクされています。リリース・ノートには、以前の更新リリースにおける修正のリストも含まれています。問題が発生した場合やバグの疑いがある場合には、診断の初期段階として、最新の更新リリースで使用可能な修正のリストをチェックしてください。
ある問題が、すでに修正されたバグと同じものであるか明確でない場合があります。利用可能な最新の更新リリースでテストし、問題が引き続き発生するかどうか確認することを常にお薦めします。
バグ・レポートの提出の準備
バグ・レポートの提出方法に関する推奨手順。
バグ・レポートを提出する前に、次の推奨事項を検討してください。
バグを提出する前に、問題が発生した環境が、サポートされている構成であることを確認します。サポートされているシステム構成を参照してください。
システム構成のほかに、サポート対象のロケールのリストも確認します。サポート対象のロケールのWebページを参照してください。
バグ・レポート用のデータの収集
一般に、利用可能な最新の更新リリースまたは利用可能な最新のアーリー・アクセス(EA)リリースでテストして、問題が引き続き発生するかどうかを確認してから、できるだけ多くの関連データを収集して、バグ・レポートを作成するかサポート・コールを行うことをお薦めします。
次の各セクションでは、収集する必要があるデータを提案し、該当する場合は、データを取得するためのコマンドや一般的な手順に関する推奨事項を説明します。
ハードウェアの詳細
致命的なエラーが発生すると、エラー・ログにハードウェアの詳細が保存されます。
特定のハードウェア構成でのみバグが発生したり再現できたりすることがあります。致命的なエラーが発生した場合は、エラー・ログにハードウェアの詳細が含まれている可能性があります。エラー・ログを入手できない場合は、マシンのプロセッサの番号と種類、クロック速度、および該当する場合かつ既知の場合は、そのプロセッサの機能に関するいくつかの詳細をバグ・レポートにまとめます。たとえばIntelプロセッサの場合、ハイパースレッディングが使用可能であることがそれに該当します。
オペレーティング・システムの詳細
オペレーティング・システムには、オペレーティング・システムの詳細を取得するために使用できるコマンドが用意されています。
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 SEのバージョン文字列は、java -version
コマンドを使用すると取得できます。
同じマシン上にJava SEのバージョンが複数インストールされている可能性があります。したがって、適切なバージョンのjava
コマンドが間違いなく使用されるように、そのインストールのbin
ディレクトリがPATH
環境変数内で他のインストールよりも前にあることを確認してください。
コマンド行オプション
バグ・レポートに致命的エラー・ログが含まれていない場合は、コマンド行全体とそのすべてのオプションを文書化することが重要です。これには、ヒープ設定を指定するオプション(-mx
オプションなど)やHotSpot固有のオプションを指定する-XX
オプションが含まれます。
Java SEの機能の1つに、ガベージ・コレクタ・エルゴノミクスがあります。サーバークラス・マシンでは、java
コマンドはHotSpot Server VMとパラレル・ガベージ・コレクタを起動します。マシンがサーバー・マシンと見なされるのは、少なくとも2基のプロセッサと2Gバイト以上のメモリーを備えている場合です。
-XX:+PrintCommandLineFlags
オプションを使用すると、コマンド行オプションを検証できます。このオプションは、コマンド行のVMに対するすべてのフラグを出力します。jmap
ユーティリティを使用すると、実行中のVMまたはコア・ファイルのコマンド行オプションを取得することもできます。
環境変数
環境変数の設定が原因で問題が発生する場合があります。バグ・レポートの作成時に、次のJava環境変数の値(設定されている場合)を記入してください。
-
JAVA_TOOL_OPTIONS
-
_JAVA_OPTIONS
-
CLASSPATH
-
JAVA_COMPILER
-
PATH
-
USERNAME
また、次のオペレーティング・システム固有の環境変数も収集してください。
致命的エラー・ログ
致命的エラー・ログは、致命的エラーの発生時に作成されます。
最新の更新リリースでテストし、問題が引き続き発生するかどうか確認することをお薦めします。
致命的エラーが発生すると、エラー・ログが作成されます。「致命的エラー・ログ」を参照してください。
このエラー・ログには、致命的エラーの発生時に得られた情報(バージョンや環境の情報、クラッシュを引き起こしたスレッドの詳細など)が含まれています。
致命的エラー・ログが生成される場合は、必ずそれをバグ・レポートに含めるか、サポート・コール時に報告してください。
コア・ダンプおよびクラッシュ・ダンプ
コア・ダンプやクラッシュ・ダンプは、システム・クラッシュまたはハングアップ・プロセスの診断を試みる際に非常に役立つ可能性があります。
ダンプの生成手順は、「コア・ダンプの収集」で説明されています。
問題の詳細な説明
問題の説明を作成するときは、できるだけ多くの関連情報を含めるようにしてください。
アプリケーション、環境、そして何よりも問題が発生した時点につながるイベントを記述します。
複雑なアプリケーション環境でしか問題を再現できない場合があります。その場合は、ログ、コア・ファイル、およびその他の関連情報を伴う説明が問題を診断する唯一の手段になる可能性があります。このような状況では、提出者が問題の発生しているシステムでさらなる診断を行ったり、テスト・バイナリを実行したりする意志があるかどうかをその説明で示すようにしてください。
- 問題が再現可能な場合は、その問題を再現するために必要なステップの一覧を示します。
- 問題を小さなテスト・ケースで再現できる場合は、そのテスト・ケースと、そのテスト・ケースをコンパイルして実行するためのコマンドを含めます。
- テスト・ケースまたは問題にサード・パーティのコード(商用またはオープン・ソースのライブラリやパッケージなど)が必要な場合は、そのライブラリの場所と入手方法についての詳細を提供します。
ログおよびトレース
ログまたはトレース出力が問題の原因を迅速に特定するのに役立つ可能性があります。
たとえば、パフォーマンスの問題の場合、-verbose:gc
オプションの出力が問題の診断に役立つ可能性があります。(これは、ガベージ・コレクタからの出力を有効にするオプションです。)
別のケースでは、jstat
コマンドからの出力を使用すると、問題の発生に至るまでの期間にわたる統計情報を取得できます。
VMのデッドロックまたはハング・アップ(ループが原因など),の場合は、スレッド・スタックが問題の診断に役立つ可能性があります。スレッド・スタックを取得するには、Linuxでは[Ctrl]+[\]、Windowsでは[Ctrl]+[Break]を押します。
通常は、関連のあるすべてのログ、トレース、およびその他の出力をバグ・レポートまたはサポート・コール時に提供します。
トラブルシューティング・ステップの結果
すでに行ったすべてのトラブルシューティングのステップと結果を報告します
たとえば、問題がクラッシュであり、アプリケーションにネイティブ・ライブラリが含まれている場合は、バグがネイティブ・コード内にある可能性を減らすために、すでに-Xcheck:jni
オプションを使用してアプリケーションを実行している場合があります。別のケースとして、HotSpot Server VM (-server
オプション)で発生するクラッシュが考えられます。HotSpot Client VM (-client
オプション)でもテストを行い、問題が発生しない場合は、バグがHotSpot Server VMに固有のものである可能性があることの目安になります。
一般に、すでに行われたトラブルシューティング・ステップと結果をすべてバグ・レポートに含めます。この種の情報によって、問題の診断に要する時間が短縮されることが頻繁にあります。
コア・ダンプの収集
コア・ダンプ(クラッシュ・ダンプとも呼ばれる)の生成および収集の手順。コア・ダンプまたはクラッシュ・ダンプとは、実行中のプロセスのメモリー・スナップショットです。
コア・ダンプは、致命的エラーまたは処理できないエラー(シグナルまたはシステム例外など)の発生時にオペレーティング・システムによって自動的に作成されることがあります。また、コア・ダンプはシステム提供のコマンド行ユーティリティを使用して強制的に取得することもできます。ハングアップしているように見えるプロセスを診断する際にコア・ダンプが役立つ場合があります。つまり、コア・ダンプによってハングアップの原因に関する情報が明らかになることがあります。
コア・ダンプを収集する場合は、コア・ファイルを解析できるように、必ず環境に関するその他の情報(OSバージョン、パッチ情報、致命的エラー・ログなど)も収集してください。
コア・ダンプには通常、クラッシュまたはハング・アップしたプロセスのメモリー・ページがすべて含まれているとはかぎりません。ここで取り上げている各オペレーティング・システムでは、プロセスのテキスト(またはコード)ページはコア・ダンプに含まれません。しかし、少なくともヒープとスタックのページがコア・ダンプに含まれていないと役に立ちません。クラッシュのポストモーテム解析には、切り詰められていない完全なコア・ダンプ・ファイルの収集が不可欠です。
次の項では、コア・ダンプの収集シナリオについて説明します。
Linuxでのコア・ダンプの収集
Linuxオペレーティング・システムでは、セグメンテーション違反や不正な命令などの処理できないシグナルによってコア・ダンプが作成されます。
デフォルトでは、コア・ダンプはプロセスの現在の作業ディレクトリに作成され、コア・ダンプ・ファイルの名前はcore.pid
になります(pid
はクラッシュしたJavaプロセスのプロセスID)。
ulimit
ユーティリティは、現在のシェルとその子孫で利用できるシステム・リソースへの制限を設定または取得するために使用されます。コア・ファイルのサイズ制限をチェックまたは設定するには、ulimit -c
コマンドを使用します。その制限が必ずunlimited
に設定されるようにしてください。そうしないと、コア・ファイルが切り詰められる可能性があります。
注意:
ulimit
はBashシェルの組込みコマンドです。Cシェルでは、limit
コマンドを使用してください。
VMまたはアプリケーションの起動に使用されるスクリプトがコア・ダンプの作成を無効にしないようにしてください。
gcore
コマンドをgdb
(GNUデバッガ)インタフェースで使用すると、実行中のプロセスのコア・イメージを取得できます。このユーティリティは、コア・ダンプを強制的に作成させるプロセスのpid
を受け入れます。
マシン上で実行されているJavaプロセスのリストを取得するには、次のいずれかのコマンドを使用できます。
-
LinuxでのShowMessageBoxOnErrorオプション:
Javaプロセスは、
-XX:+ShowMessageBoxOnError
コマンド行オプションを使って起動できます。致命的エラーが発生すると、そのプロセスは標準エラーにメッセージを出力し、標準入力からの「yes
」または「no
」の応答を待ちます。次の例は、予期しないシグナルが発生した場合の出力を示しています。======================================================================= Unexpected Error ----------------------------------------------------------------------- SIGSEGV (0xb) at pc=0x06232e5f, pid=11185, tid=8194 Do you want to debug the problem? To debug, run 'gdb /proc/11185/exe 11185'; then switch to thread 8194 Enter 'yes' to launch gdb automatically (PATH must include gdb) Otherwise, press RETURN to abort... =======================================================================
示されたエラー・レポートで示唆されているように、
gdb
(GNUデバッガ)インタフェースを起動するには、「yes
」と入力します。gdb
プロンプトで、gcore
コマンドを指定できます。このコマンドは、デバッグされたプロセスのコア・ダンプをcore.pid
という名前で作成します(pid
はクラッシュしたプロセスのプロセスID)。使用しているgdb
バージョンでgdb gcore
コマンドがサポートされていることを確認してください。gdb
コマンド・プロンプトで、help gcore
を確認してください。
コア・ファイルを取得しない理由
コア・ファイルが生成されない場合がある理由のリスト。
このリストは、Linuxオペレーティング・システムに関連します。
-
ユーザーに、そのプロセスの現在の作業ディレクトリへの書込み権がありません。
-
ユーザーには現在の作業ディレクトリへの書込み権がありますが、読取り専用の権限を持つ
core
という名前のファイルがすでに存在しています。 -
現在のディレクトリに十分な空き領域がないか、空き領域がまったく残っていません。
-
現在のディレクトリに、
core
という名前のサブディレクトリがあります。 -
現在の作業ディレクトリがリモートです。ネットワーク・ファイル・システム(NFS)によってマップされている可能性があり、コア・ダンプが作成されようとしているときにNFSが失敗しました。
-
コア・ファイルのサイズ制限が低すぎます。
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でのクラッシュ・ダンプの収集
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つの方法です。