一般に、利用可能な最新の更新リリースまたは利用可能な最新のEA (アーリー・アクセス)リリースでテストして、問題が引き続き発生するかどうかを確認してから、できるだけ多くの関連データを収集して、バグ・レポートを作成するかサポート・コールを行うことが推奨されます。次の各セクションでは、収集すべきデータを提案し、該当する場合は、データを取得するためのコマンドや一般的な手順に関する推奨事項を提供します。
特定のハードウェア構成でのみバグが発生したり再現できたりすることがあります。致命的なエラーが発生した場合は、エラー・ログにハードウェアの詳細が含まれている可能性があります。エラー・ログを入手できない場合は、マシンのプロセッサの番号と種類、クロック速度、および該当する場合かつ既知の場合は、そのプロセッサの機能に関するいくつかの詳細をバグ・レポートにまとめます。たとえば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
コマンドが間違いなく使用されるように、そのインストールのbinディレクトリがPATH
環境変数内で他のインストールよりも前にあることを確認してください。
バグ・レポートに致命的エラー・ログが含まれていない場合は、コマンド行全体とそのすべてのオプションを文書化することが重要です。これには、ヒープ設定を指定するオプション(-mx
オプションなど)やHotSpot固有のオプションを指定する-XX
オプションが含まれます。
Java SEの機能の1つに、ガベージ・コレクタ・エルゴノミクスがあります。サーバークラス・マシンでは、java
コマンドはHotSpot Server VMとパラレル・ガベージ・コレクタを起動します。マシンがサーバー・マシンと見なされるのは、少なくとも2基のプロセッサと2Gバイト以上のメモリーを備えている場合です。
-XX:+PrintCommandLineFlags
オプションを使用すると、コマンド行オプションを検証できます。このオプションは、コマンド行のVMに対するすべてのフラグを出力します。jmap
ユーティリティを使用すると、実行中のVMまたはコア・ファイルのコマンド行オプションを取得することもできます。
環境変数の設定が原因で問題が発生する場合があります。バグ・レポートの作成時に、次のJava環境変数の値(設定されている場合)を記入してください。
JAVA_HOME
JRE_HOME
JAVA_TOOL_OPTIONS
_JAVA_OPTIONS
CLASSPATH
JAVA_COMPILER
PATH
USERNAME
また、次のオペレーティング・システム固有の環境変数も収集してください。
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
最新の更新リリースでテストし、問題が引き続き発生するかどうか確認することをお薦めします。
致命的エラーが発生すると、エラー・ログが作成されます。このファイルの詳細は、付録Aを参照してください。
このエラー・ログには、致命的エラーの発生時に得られた多くの情報(バージョンや環境の情報、クラッシュを引き起こしたスレッドの詳細など)が含まれています。
致命的エラー・ログが生成される場合は、必ずそれをバグ・レポートやサポート・コールに含めてください。
コア・ダンプやクラッシュ・ダンプは、システム・クラッシュまたはハングアップ・プロセスの診断を試みる際に非常に役立つ可能性があります。ダンプの生成手順は、「コア・ダンプの収集」で説明されています。
問題の説明を作成するときは、できるだけ多くの関連情報を含めるようにしてください。アプリケーション、環境、そして何よりも問題が発生した時間につながるイベントを記述します。
問題が再現可能な場合は、その問題を再現するために必要な手順の一覧を示します。
問題を小さなテスト・ケースで再現できる場合は、そのテスト・ケースと、そのテスト・ケースをコンパイルして実行するためのコマンドを含めます。
テスト・ケースまたは問題にサード・パーティのコード(商用またはオープン・ソースのライブラリやパッケージなど)が必要な場合は、そのライブラリの場所と入手方法についての詳細を提供します。
複雑なアプリケーション環境でしか問題を再現できない場合があります。その場合は、ログ、コア・ファイル、およびその他の関連情報を伴う説明が問題を診断する唯一の手段になる可能性があります。このような状況では、提出者が問題の発生しているシステムでさらなる診断を行なったり、テスト・バイナリを実行したりする意志があるかどうかをその説明で示すようにしてください。
場合によっては、ログまたはトレース出力が問題の原因を迅速に特定するのに役立つ可能性があります。
たとえば、パフォーマンスの問題の場合、-verbose:gc
オプションの出力が問題の診断に役立つ可能性があります。(これは、ガベージ・コレクタからの出力を有効にするオプションです。)
別のケースでは、jstat
コマンドからの出力を使用すると、問題の発生に至るまでの期間にわたる統計情報を取得できます。
VMのデッドロックまたはハング・アップ(ループが原因など)の場合は、スレッド・スタックが問題の診断に役立つ可能性があります。スレッド・スタックを取得するには、Oracle SolarisおよびLinuxでは[Ctrl]+[\]、Windowsでは[Ctrl]+[Break]を押します。
通常は、関連のあるすべてのログ、トレース、およびその他の出力をバグ・レポートまたはサポート・コールに含めます。
バグ・レポートを提出する前に、必ず、実行したトラブルシューティング手順をすべて文書化してください。
たとえば、問題がクラッシュであり、アプリケーションにネイティブ・ライブラリが含まれている場合は、バグがネイティブ・コード内にある可能性を減らすために、すでに-Xcheck:jni
オプションを使ってアプリケーションを実行している場合があります。別のケースとして、HotSpot Server VM (-server
オプション)で発生するクラッシュが考えられます。HotSpot Client VM (-client
オプション)でもテストを行い、問題が発生しない場合は、バグがHotSpot Server VMに固有のものである可能性があることの目安になります。
一般に、すでに行われたトラブルシューティング手順と結果をすべてバグ・レポートに含めます。この種の情報によって、問題の診断に要する時間が短縮されることが頻繁にあります。