Java Platform, Standard Editionトラブルシューティング・ガイド
目次   前   次

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

一般に、利用可能な最新の更新リリースまたは利用可能な最新のEA (アーリー・アクセス)リリースでテストして、問題が引き続き発生するかどうかを確認してから、できるだけ多くの関連データを収集して、バグ・レポートを作成するかサポート・コールを行うことが推奨されます。 次の各セクションでは、収集すべきデータを提案し、該当する場合は、データを取得するためのコマンドや一般的な手順に関する推奨事項を提供します。

17.3.1 問題の詳細な説明

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

アプリケーション、環境、そして問題が発生した時点につながる最も重要なイベントを記述します。

すでに行ったすべてのトラブルシューティングのステップと結果を報告します

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

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

17.3.2 ハードウェアの詳細

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

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

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.4 Java SEのバージョン

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

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

17.3.5 コマンド行オプション

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

問題を再現でき、JVMの標準出力(標準出力)を読み取ることができる場合は、-XX:+PrintCommandLineFlagsオプションを追加して、アプリケーションで使用されるコマンドライン・オプションの完全なリストを取得できます。 このオプションは、次回JVMを再起動したときにアクティブになります。

jcmd (Windows)/「jcmd (Oracle SolarisおよびLinux)」コマンドを次のように実行して、実行中のVMのコマンドライン・オプションを取得することもできます:

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

また、jcmdを使用して、実行中のJVMのフラグを変更できます。 VM.set_flagコマンドを参照してください。

17.3.6 環境変数

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

  • JAVA_TOOL_OPTIONS
  • _JAVA_OPTIONS
  • CLASSPATH
  • JAVA_COMPILER
  • PATH
  • USERNAME

ノート:

障害が発生したアプリケーションのコンテキストから環境変数の値を取得する必要があります。 さらに、1つ以上の構成ファイルで、障害が発生したアプリケーションに対してこれらの環境変数の値を設定できます。

また、次のオペレーティング・システム固有の環境変数も収集してください。

  • Oracle SolarisおよびLinuxオペレーティング・システムでは、次の環境変数の値を収集します。
    • LD_LIBRARY_PATH
    • LD_PRELOAD
  • Windowsでは、次の環境変数の値を収集します:
    • OS
    • PROCESSOR_IDENTIFIER
    • _ALT_JAVA_HOME_DIR

17.3.7 致命的エラー・ログ

致命的エラーが発生すると、エラー・ログが作成されます。 このファイルの詳細は、「付録A: 致命的エラー・ログ」を参照してください。

このエラー・ログには、致命的エラーの発生時に得られた多くの情報(バージョンや環境の情報、クラッシュを引き起こしたスレッドの詳細など)が含まれています。

致命的エラー・ログが生成される場合は、必ずそれをバグ・レポートやサポート・コールに含めてください。

17.3.8 コア・ダンプまたはクラッシュ・ダンプ

報告された問題が原因でコア・ファイルまたはクラッシュ・ダンプが作成された場合は、それをバグ、サイズ許可とともに含めます。

Linuxコア・ファイルまたはWindowsクラッシュ・ダンプには、コアまたはダンプが作成された時点のアプリケーションまたはオペレーティング・システムのメモリー状態が含まれます。 システムの構成によっては、クラッシュが発生したときにコア・ダンプまたはクラッシュ・ダンプが自動的に作成される場合があります。 システム管理者に問い合せて、コア・ファイルが自動的に生成されるかどうか、およびどこに生成されるかを判断してください。

ハングアップ・プロセスの場合、ダンプを生成する手順については、「コア・ダンプの収集」を参照してください。

17.3.9 ログおよびトレース

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

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

また、Java Flight Recorderの(「Java Flight Recordingとは」を参照してください)およびJDK Mission Controlを使用して、問題に至るまでの期間にわたって統計情報を取得できます。


ノート:

Java Flight Recorder (JFR)は商用機能です。 開発者コンピュータでは無料で、テスト環境、開発環境、本番環境では評価目的で利用できます。 ただし、JFRを本番サーバーで有効にする場合は、商用ライセンスが必要です。 JDKのMission Controlユーザー・インタフェースを、純粋に診断目的でフライト・レコーディングを生成するなど、JDK上の他の目的に使用しても、商用ライセンスは必要ありません。 JFRの商用機能および可用性の詳細は、Oracle Java SE Universal Subscriptionを参照してください。

VMのデッドロックまたはハングの場合は、スレッド・スタックが問題の診断に役立つ可能性があります。 Oracle SolarisおよびLinuxのControl+\またはWindowsのControl+Breakを押して、スレッド・スタックを取得します。 または、jcmd (Windows)/「jcmd (Oracle SolarisおよびLinux)」コマンドでThread.dump_to_fileオプションを使用します。

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

目次   前   次
Copyright © 1993, 2025, Oracle and/or its affiliates. All rights reserved.