17.3 バグ・レポート用のデータの収集

17.3.1 ハードウェアの詳細

特定のハードウェア構成でのみバグが発生したり再現できたりすることがあります。致命的なエラーが発生した場合は、エラー・ログにハードウェアの詳細が含まれている可能性があります。エラー・ログを入手できない場合は、マシンのプロセッサの番号と種類、クロック速度、および該当する場合かつ既知の場合は、そのプロセッサの機能に関するいくつかの詳細をバグ・レポートにまとめます。たとえばIntelプロセッサの場合、ハイパースレッディングが使用可能であることがそれに該当します。

17.3.2 オペレーティング・システムの詳細

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ライブラリとともに使用している可能性があります。

17.3.3 Java SEのバージョン

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

同じマシン上にJava SEのバージョンが複数インストールされている可能性があります。したがって、適切なバージョンのjavaコマンドが間違いなく使用されるように、そのインストールのbinディレクトリがPATH環境変数内で他のインストールよりも前にあることを確認してください。

17.3.4 コマンド行オプション

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

Java SEの機能の1つに、ガベージ・コレクタ・エルゴノミクスがあります。サーバークラス・マシンでは、javaコマンドはHotSpot Server VMとパラレル・ガベージ・コレクタを起動します。マシンがサーバー・マシンと見なされるのは、少なくとも2基のプロセッサと2Gバイト以上のメモリーを備えている場合です。

-XX:+PrintCommandLineFlagsオプションを使用すると、コマンド行オプションを検証できます。このオプションは、コマンド行のVMに対するすべてのフラグを出力します。jmapユーティリティを使用すると、実行中のVMまたはコア・ファイルのコマンド行オプションを取得することもできます。

17.3.5 環境変数

環境変数の設定が原因で問題が発生する場合があります。バグ・レポートの作成時に、次の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

17.3.8 問題の詳細な説明

問題の説明を作成するときは、できるだけ多くの関連情報を含めるようにしてください。アプリケーション、環境、そして何よりも問題が発生した時間につながるイベントを記述します。

• 問題が再現可能な場合は、その問題を再現するために必要な手順の一覧を示します。

• 問題を小さなテスト・ケースで再現できる場合は、そのテスト・ケースと、そのテスト・ケースをコンパイルして実行するためのコマンドを含めます。

• テスト・ケースまたは問題にサード・パーティのコード(商用またはオープン・ソースのライブラリやパッケージなど)が必要な場合は、そのライブラリの場所と入手方法についての詳細を提供します。

複雑なアプリケーション環境でしか問題を再現できない場合があります。その場合は、ログ、コア・ファイル、およびその他の関連情報を伴う説明が問題を診断する唯一の手段になる可能性があります。このような状況では、提出者が問題の発生しているシステムでさらなる診断を行なったり、テスト・バイナリを実行したりする意志があるかどうかをその説明で示すようにしてください。

17.3.9 ログおよびトレース

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

たとえば、パフォーマンスの問題の場合、-verbose:gcオプションの出力が問題の診断に役立つ可能性があります。(これは、ガベージ・コレクタからの出力を有効にするオプションです。)

別のケースでは、jstatコマンドからの出力を使用すると、問題の発生に至るまでの期間にわたる統計情報を取得できます。

VMのデッドロックまたはハング・アップ(ループが原因など)の場合は、スレッド・スタックが問題の診断に役立つ可能性があります。スレッド・スタックを取得するには、Oracle SolarisおよびLinuxでは[Ctrl]+[\]、Windowsでは[Ctrl]+[Break]を押します。

通常は、関連のあるすべてのログ、トレース、およびその他の出力をバグ・レポートまたはサポート・コールに含めます。

17.3.10 トラブルシューティング手順の結果

バグ・レポートを提出する前に、必ず、実行したトラブルシューティング手順をすべて文書化してください。

たとえば、問題がクラッシュであり、アプリケーションにネイティブ・ライブラリが含まれている場合は、バグがネイティブ・コード内にある可能性を減らすために、すでに-Xcheck:jniオプションを使ってアプリケーションを実行している場合があります。別のケースとして、HotSpot Server VM (-serverオプション)で発生するクラッシュが考えられます。HotSpot Client VM (-clientオプション)でもテストを行い、問題が発生しない場合は、バグがHotSpot Server VMに固有のものである可能性があることの目安になります。

一般に、すでに行われたトラブルシューティング手順と結果をすべてバグ・レポートに含めます。この種の情報によって、問題の診断に要する時間が短縮されることが頻繁にあります。