第 17 章 dbx による Java アプリケーションのデバッグ

この章では、dbx を使用して、Java コードと C JNI (Java Native Interface) コードまたは C++ JNI コードが混在するアプリケーションをデバッグする方法を説明します。

この章は次の節で構成されています。

• 「dbx と Java コード」

• 「Java デバッグ用の環境変数」

• 「Java アプリケーションのデバッグの開始」

• 「JVM ソフトウェアの起動方法のカスタマイズ」

• 「dbx の Java コードデバッグモード」

• 「Java モードにおける dbx コマンドの使用法」

dbx と Java コード

Oracle Solaris Studio の dbx を使い、Oracle Solaris OS および Linux OS で動作する混在コード (Java コードと C コードまたは C++ コード) をデバッグすることができます。

Java コードに対する dbx の機能

dbx で数種類の Java アプリケーションをデバッグすることができます (「Java アプリケーションのデバッグの開始」を参照)。大部分の dbx コマンドは、ネイティブコードと Java コードのどちらにも同様の働きをします。

Java コードのデバッグにおける dbx の制限事項

dbx は、Java コードをデバッグする場合、次の制限事項があります。

• ネイティブコードのときと異なり、コアファイルから Java アプリケーションの状態情報を入手することはできません。

• Java アプリケーションが何らかの理由で停止し、dbx が手続きを呼び出せない場合、Java アプリケーションの状態情報を入手することはできません。

• Java アプリケーションに、fix と cont、および実行時検査は使用できません。

Java デバッグ用の環境変数

ここでは、dbx を使った Java アプリケーションデバッグの専用の環境変数を説明します。JAVASRCPATH、CLASSPATHX、および jvm_invocation 環境変数を、dbx を起動する前にシェルプロンプトで設定するか、dbx コマンド行から設定します。jdbx_mode 環境変数の設定は、アプリケーションのデバッグ中に変化します。ただし、jon コマンド (「jon コマンド」) と joff コマンド (「joff コマンド」) を使って変更することも できます。

Java アプリケーションのデバッグの開始

dbx では、次の種類の Java アプリケーションをデバッグすることができます。

• .class で終わるファイル名を持つファイル

• .jar で終わるファイル名を持つファイル

• ラッパーを使って起動する Java アプリケーション

• デバッグモードで起動した実行中の Java アプリケーションを dbx で接続 (アタッチ) する

• JNI_CreateJavaVM インタフェースを使って Java アプリケーションを埋め込む C および C++ アプリケーション

dbx は、これらのどの場合もデバッグ対象が Java アプリケーションであることを認識します。

クラスファイルのデバッグ

次の例に示すように dbx を使用することによって、ファイル名拡張子が .class のファイルをデバッグすることができます。

(dbx) debug myclass.class

アプリケーションを定義しているクラスがパッケージに定義されている場合は、JVM ソフトウェアの制御下でアプリケーションを実行するときと同じで、次の例に示すように、パッケージのパスを指定する必要があります。

(dbx) debug java.pkg.Toy.class

クラスファイルのフルパス名を使用することもできます。この場合、dbx は .class ファイル内を調べることによってクラスパスのパッケージ部分を自動的に特定し、フルパス名の残りの部分をクラスパスに追加します。たとえば次のパス名の場合、dbx は pkg/Toy.class を主クラス名と判断し、クラスパスに /home/user/java を追加します。

(dbx) debug /home/user/java/pkg/Toy.class

JAR ファイルのデバッグ

Java アプリケーションは、JAR (Java Archive) ファイルにバンドルすることができます。JAR ファイルは、次の例に示すように dbxを使用することによってデバッグすることができます。

(dbx) debug myjar.jar

ファイル名が .jar で終わるファイルのデバッグを開始すると、dbx は、その JAR ファイルのマニフェストに指定されている Main_Class 属性を使って主クラスを特定します (主クラスは、アプリケーションのエントリポイントになっている、JAR ファイル内のクラスです)。フルパス名または相対パス名を使って JAR ファイルが指定された場合、dbx は Main-Class 属性のクラスパスの前にそのディレクトリ名を追加します。

Main-Class 属性を持たない JAR ファイルをデバッグする場合、JAR URL 構文 jar:<url>!/{entry} を使用できます。この構文は、次の例のように、主クラスの名前を指定するために JarURLConnection (Java 2 Platform, Standard Edition のクラス) で指定されています。

(dbx) debug jar:myjar.jar!/myclass.class
(dbx) debug jar:/a/b/c/d/e.jar!/x/y/z.class
(dbx) debug jar:file:/a/b/c/d.jar!/myclass.class

これらの例のどの場合も、dbx は次のことを行います。

• 文字 ! のあとに指定されたクラスパスを主クラスとみなします (例: /myclass.class または /x/y/z.class)。

• JAR ファイルの名前 /myjar.jar、/a/b/c/d/e.jar、または /a/b/c/d.jar をクラスパスに追加します。

• 主クラスのデバッグを開始します。

  ---

  注 –

  jvm_invocation 環境変数を使って JVM ソフトウェアの起動方法をカスタマイズした場合は (「JVM ソフトウェアの起動方法のカスタマイズ」を参照)、JAR ファイルのファイル名がクラスパスに追加されません。この場合は、デバッグを開始するときに JAR ファイルのファイル名をクラスパスに手動で追加する必要があります。

  ---

ラッパーを持つ Java アプリケーションのデバッグ

通常 Java アプリケーションには、環境変数を設定するためのラッパーがあります。Java アプリケーションにラッパーがある場合は、jvm_invocation 環境変数を設定することによって、ラッパースクリプトを使用することを dbx に知らせる必要があります (「JVM ソフトウェアの起動方法のカスタマイズ」を参照)。

動作中の Java アプリケーションへの dbx の接続

dbx を動作中の Java アプリケーションに接続するには、アプリケーションを起動するときに次の例に示すオプションを指定します。アプリケーションが起動すると、動作中のプロセスのプロセス ID を指定して dbx コマンドを実行することによって、デバッグを開始することができます (「dbx コマンド」を参照)。

$ java -Djava.compiler=NONE -Xdebug -Xnoagent -Xrundbx_agent myclass.class
$ dbx - 2345

JVM ソフトウェアが libdbx_agent.so を見つけられるようにするには、Java アプリケーションを実行する前に正しいパスを LD_LIBRARY_PATH に追加する必要があります。

• Solaris OS を実行しているシステムで 32 ビットの JVM ソフトウェアを使用している場合は、/installation_directory /SUNWspro/lib/libdbx_agent.so を追加します。

• Solaris OS を実行している SPARC システムで 64 ビットの JVM ソフトウェアを使用している場合は、/installation_directory /SUNWspro/lib/v9/libdbx_agent.so を LD_LIBRARY_PATH に追加します。

• Linux OS を実行している x64 システムで 64 ビットの JVM ソフトウェアを使用している場合は、/installation_directory/sunstudio12/lib/amd64/libdbx_agent.so を LD_LIBRARY_PATH に追加します。

installation_directory は Oracle Solaris Studio ソフトウェアがインストールされている場所です。

動作中のアプリケーションに dbx を接続すると、dbx は Java モードでアプリケーションのデバッグを開始します。

Java アプリケーションが 64 ビットのオブジェクトライブラリを必要とする場合は、アプリケーションを起動するときに -d64 オプションを追加してください。この場合、dbx はアプリケーションが動作している 64 ビットの JVM ソフトウェアを使用します。

$ java -Djava.compiler=NONE -Xdebug -Xnoagent -Xrundbx_agent -d64 myclass.class
$ dbx - 2345

Java アプリケーションを埋め込む C/C++ アプリケーションのデバッグ

JNI_CreateJavaVM インタフェースを使って Java アプリケーションを埋め込む C あるいは C++ アプリケーションをデバッグすることができます。この場合、C/C++ アプリケーションは、JVM ソフトウェアに次のオプションを指定することによって Java アプリケーションを起動することができます。

-Xdebug -Xnoagent -Xrundbx_agent

JVM ソフトウェアが libdbx_agent.so を見つけられるようにするには、Java アプリケーションを実行する前に正しいパスを LD_LIBRARY_PATH に追加する必要があります。

• Solaris OS を実行しているシステムで 32 ビットの JVM ソフトウェアを使用している場合は、/installation_directory /SUNWspro/lib/libdbx_agent.so を LD_LIBRARY_PATH に追加します。

• Solaris OS を実行している SPARC システムで 64 ビットの JVM ソフトウェアを使用している場合は、/installation_directory /SUNWspro/lib/v9/libdbx_agent.so を LD_LIBRARY_PATH に追加します。

• Linux OS を実行している x64 システムで 64 ビットの JVM ソフトウェアを使用している場合は、/installation_directory /sunstudio12/lib/amd64/libdbx_agent.so を LD_LIBRARY_PATH に追加します。

installation_directory は Oracle Solaris Studio ソフトウェアがインストールされている場所です。

JVM ソフトウェアへの引数の引き渡し

Java モードで run コマンドを使用した場合、指定した引数は、JVM ソフトウェアではなく、アプリケーションに渡されます。 JVM ソフトウェアに引数を渡す方法については、「JVM ソフトウェアの起動方法のカスタマイズ」を参照してください。

Java ソースファイルの格納場所の指定

Java ソースファイルが、.class や .jar ファイルと異なるディレクトリに置かれていることがあります。その場合は、$JAVASRCPATH 環境変数を使って、dbx が Java ソースファイルを探すディレクトリを指定することができます。たとえば、JAVASRCPATH=.:/mydir/mysrc:/mydir/mylibsrc:/mydir/myutils の場合、dbx は指定されたディレクトリで、デバッグ対象のクラスファイルに対応するソースファイルを探します。

C/C++ ソースファイルの格納場所の指定

次の場合は、dbx が C/C++ ソースファイルを見つけられないことがあります。

• ソースファイルの現在の格納場所がコンパイルしたときにあった場所と異なる場合

• dbx を実行しているシステムとは異なるシステムでソースファイルをコンパイルし、コンパイルディレクトリのパス名が異なる場合

このような場合、dbx がファイルを見つけられるよう、pathmap コマンドを使ってパス名を別のパス名に対応づけてください (「pathmap コマンド」を参照)。

独自のクラスローダーを使用するクラスファイルのパスの指定

通常のクラスパスに含まれてない場所からクラスファイルを読み込む独自のクラスローダーが、アプリケーションに存在することがあります。そのような場合、dbx はクラスファイルを見つけられません。CLASSPATHX 環境変数を使って、独自のクラスローダーが読み込む Java クラスファイルのパスを指定することができます。たとえば、CLASSPATHX=.:/myloader/myclass:/mydir/mycustom の場合、dbx は指定されたディレクトリでクラスファイルを探そうとします。

Java メソッドにブレークポイントを設定する

ネイティブアプリケーションとは異なり、Java アプリケーションには容易にアクセスできる名前のインデックスがありません。そのため、次のように簡単に入力することはできません。

(dbx) stop in myMethod

代わりに、メソッドへのフルパスを使用する必要があります。

(dbx) stop in com.any.library.MyClass.myMethod

例外は、MyClass の何らかのメソッドで停止した場合で、その場合は myMethod で十分です。

フルパスをメソッドに含めることを防ぐ 1 つの方法は、stop inmethod を使用することです。

(dbx) stop inmethod myMethod

しかしそうすると、複数メソッド名 myMethod で停止してしまう場合があります。

ネイティブ (JNI) コードでブレークポイントを設定する

JNI C または C++ コードを含む共有ライブラリは JVM によって動的に読み込まれ、それらにブレークポイントを設定するには、いくつかの追加のステップが必要です。詳しくは、「動的にロードされたライブラリにブレークポイントを設定する」を参照してください。

JVM ソフトウェアの起動方法のカスタマイズ

次のことを行うために、dbx からの JVM ソフトウェアの起動方法のカスタマイズが必要になることがあります。

• JVM ソフトウェアのパス名を指定します (「JVM ソフトウェアのパス名の指定」を参照)。

• JVM ソフトウェアに run の引数を渡します (「JVM ソフトウェアへの実行引数の引き渡し」を参照)。

• Java アプリケーションの実行に際してデフォルトの Java ラッパーではなく独自のラッパーを指定します (「Java アプリケーション用の独自のラッパーの指定」を参照)。

• 64 ビットの JVM ソフトウェアを指定します (「64 ビット JVM ソフトウェアの指定」を参照)。

JVM ソフトウェアの起動方法のカスタマイズは、jvm_invocation 環境変数を使って行うことができます。jvm_invocation 環境変数が定義されていない場合、デフォルトでは dbx は次の設定で JVM ソフトウェアを起動します。

java -Xdebug -Xnoagent -Xrundbx_agent:syncpid

jvm_invocation 環境変数が定義されている場合は、その変数の値を使って JVM ソフトウェアを起動します。

jvm_invocation 環境変数の定義には、-Xdebug オプションを含める必要があります。dbx は、-Xdebug を内部オプションの -Xdebug Xnoagent -Xrundbxagent::sync に展開します。

次の例に示すように -Xdebug オプションが定義に含まれていない場合は、dbx からエラーメッセージが発行されます。

jvm_invocation="/set/java/javasoft/sparc-S2/jdk1.2/bin/java"

dbx: Value of `$jvm_invocation’ must include an option to invoke the VM in debug mode

JVM ソフトウェアのパス名の指定

デフォルトでは、JVM ソフトウェアにパス名を指定しなかった場合、dbx はパス内の JVM ソフトウェアを起動します。

JVM ソフトウェアのパス名を指定するには、次の例に示すように、jvm_invocation 環境変数に適切なパス名を設定します。

jvm_invocation="/myjava/java -Xdebug"

この設定の場合、dbx は次の設定で JVM ソフトウェアを起動します。

/myjava/java -Djava.compiler=NONE -Xdebug -Xnoagent -Xrundbx_agent:sync

JVM ソフトウェアへの実行引数の引き渡し

JVM ソフトウェアに実行引数を渡すには、次の例に示すように jvm_invocation 環境変数を設定することによって、それらの引数を付けて JVM ソフトウェアを起動します。

jvm_invocation="java -Xdebug -Xms512 -Xmx1024 -Xcheck:jni"

この場合、dbx は次の設定で JVM ソフトウェアを起動します。

java -Djava.compiler=NONE -Xdebug -Xnoagent -Xrundbx_agent:sync= -Xms512 -Xmx1024 -Xcheck:jni

Java アプリケーション用の独自のラッパーの指定

Java アプリケーションは起動時に独自のラッパーを使用することができます。その場合は、次の例に示すように jvm_invocation 環境変数を使って、利用するラッパーを指定します。

jvm_invocation="/export/siva-a/forte4j/bin/forte4j.sh -J-Xdebug"

この場合、dbx は次の設定で JVM ソフトウェアを起動します。

/export/siva-a/forte4j/bin/forte4j.sh - -J-Xdebug -J-Xnoagent -J-Xrundbxagent:sync=process_id

コマンド行オプションを受け付ける独自のラッパーの利用

次のラッパースクリプト (xyz) は複数の環境変数を設定して、コマンド行オプションを受け付けます。

#!/bin/sh
CPATH=/mydir/myclass:/mydir/myjar.jar; export CPATH
JARGS="-verbose:gc -verbose:jni -DXYZ=/mydir/xyz"
ARGS=
while [ $# -gt 0 ] ; do
    case "$1" in
        -userdir) shift; if [ $# -gt 0 ]
; then userdir=$1; fi;;
        -J*) jopt=`expr $1 : ’-J<.*>’`
; JARGS="$JARGS ’$jopt’";;
        *) ARGS="$ARGS ’$1’" ;;
    esac
    shift
done
java $JARGS -cp $CPATH $ARGS

このスクリプトは、JVM ソフトウェアとユーザーアプリケーション用のコマンド行オプションを受け付けます。この形式のラッパースクリプトに対しては、次のように jvm_invocation 環境変数を設定して、dbx を起動します。

% jvm_invocation="xyz -J-Xdebug -Jany other java options"
% dbx myclass.class -Dide=visual

コマンド行オプションを受け付けない独自のラッパーの利用

次のラッパースクリプト (xyz) は複数の環境変数を設定して、JVM ソフトウェアを起動しますが、コマンド行オプションやクラス名を受け付けません。

#!/bin/sh
CLASSPATH=/mydir/myclass:/mydir/myjar.jar; export CLASSPATH
ABC=/mydir/abc; export ABC
java <options> myclass

このようなスクリプトを次のいずれかの方法で利用し、dbx を使ってラッパーをデバッグすることもできます。

• jvm_invocation 変数の定義をスクリプトに追加することによって、ラッパースクリプトそのものから dbx が起動されるようにスクリプトを変更する。

  #!/bin/sh CLASSPATH=/mydir/myclass:/mydir/myjar.jar; export CLASSPATH ABC=/mydir/abc; export ABC jvm_invocation="java -Xdebug <options>"; export jvm_invocation dbx myclass.class

  この変更を行うと、スクリプトを実行することによってデバッグセッションを開始することができます。

• 次に示すようにスクリプトを少し変更して、コマンド行オプションを受け付けられるようにする。

  #!/bin/sh CLASSPATH=/mydir/myclass:/mydir/myjar.jar; export CLASSPATH ABC=/mydir/abc; export ABC JAVA_OPTIONS="$1 <options>" java $JAVA_OPTIONS $2

  この変更を行なったら、次のように jvm_invocation 環境変数を設定して、dbx を起動します。

  % jvm_invocation="xyz -Xdebug"; export jvm_invocation % dbx myclass.class

64 ビット JVM ソフトウェアの指定

dbx で 64 ビットの JVM ソフトウェアを起動して、64 ビットのオブジェクトライブラリを必要とするアプリケーションをデバッグするには、jvm_invocation 環境変数の定義に -d64 オプションを含めます。

jvm_invocation="/myjava/java -Xdebug -d64"

dbx の Java コードデバッグモード

Java アプリケーションのデバッグの場合、dbx は次の 3 つのモードのいずれかで動作します。

• Java モード

• JNI モード

• ネイティブモード

Java または JNI (Java Native Interface) モードでは、JNI コードを含めて Java アプリケーションの状態を調べ、コードの実行を制御することができます。ネイティブモードでは、C または C++ JNI コードの状態を調べることができます。現在のモード (java、jni、native) は、jdbx_mode 環境変数に記憶されます。

Java モードでは、Java 構文を使用して dbx と対話します。dbx も Java 構文を使用して情報を提供します。このモードは、純粋な Java コードか、Java コードと C JNI または C++ JNI コードが混在するアプリケーション内の Java コードのデバッグに使用します。

JNI モードでは、dbx はネイティブの構文を使用して、ネイティブコードにだけ作用しますが、コマンドの出力には、ネイティブの状態ばかりでなく、Java 関係の状態も示されるため、JNI モードは「混在」モードです。このモードは、Java コードと C JNI または C++ JNI コードが混在するアプリケーションのネイティブ部分のデバッグに使用します。

ネイティブモードでは、dbx コマンドはネイティブのプログラムにだけ作用し、Java 関係の機能はすべて無効になります。このモードは Java が関係しないプログラムのデバッグに使用します。

Java アプリケーションを実行すると、dbx は状況に応じて Java モードと JNI モードを自動的に切り替えます。たとえば、Java ブレークポイントを検出すると、dbx は Java モードに切り替わり、Java コードから JNI コードに入ると、JNI モードに切り替わります。

Java または JNI モードからネイティブモードへの切り替え

dbx は、自動的にはネイティブモードに切り替わりません。Java または JNI モードからネイティブモードへは joff コマンド、ネイティブモードから Java モードへは jon コマンドを使って明示的に切り替えることができます。

実行中断時のモードの切り替え

たとえば Ctrl-C を使って Java アプリケーションの実行が中断された場合、dbx はアプリケーションを安全な状態にして、すべてのスレッドを一時停止することによって、自動的にモードを Java/JNI モードに切り替えようとします。

アプリケーションを一時停止して Java/JNI モードに切り替えることができない場合、dbx はネイティブモードに切り替わります。 この場合でも、jon コマンドを使用して、Java モードに切り替え、プログラムの状態を調べることができます。

Java モードにおける dbx コマンドの使用法

Java コードとネイティブコードが混在するアプリケーションのデバッグに使用する dbx コマンドは、次のように分類することができます。

• 受け付ける引数と機能が Java/JNI モードとネイティブモードで完全に同じコマンド (「構文と機能が Java モードとネイティブモードで完全に同じコマンド」を参照)。

• Java または JNI モードとネイティブモードの間で有効な引数が異なるコマンド (「Java モードで構文が異なる dbx コマンド」を参照)。

• Java または JNI モードでのみ有効なコマンド (「Java モードでのみ有効なコマンド」を参照)。

どの分類にも属さないコマンドはすべてネイティブモードでのみ動作します。

dbx コマンドにおける Java の式の評価

大部分の dbx コマンドで使用される Java の式の評価機能は次の構造をサポートしています。

• すべてのリテラル

• すべての名前とフィールドアクセス

• this および super

• 配列アクセス

• キャスト

• 条件付きの二項演算

• メソッドの呼び出し

• その他の単項/二項演算

• 変数またはフィールドへの値の代入

• instanceof 演算子

• 配列の長さ演算子

サポートされていない構造は次のとおりです。

• 修飾付きの this (例: <ClassName>.this)

• クラスのインスタンス作成式

• 配列の作成式

• 文字列連結演算子

• 条件演算子 ?::

• 複合代入演算子 (例 : x += 3)

Java アプリケーションの状態を調べるうえで特に有用なのは、IDE または dbxtool の監視機能を利用する方法です。

データを調べる以上の操作を行う式に対して正確な値解釈を依存します。

dbx コマンドが利用する静的および動的情報

通常、Java アプリケーションに関する情報の多くは、JVM ソフトウェアが起動してからのみ利用でき、終了すると利用できなくなります。ただし、Java アプリケーションのデバッグでは、dbx は、JVM ソフトウェアを起動する前にシステムクラスパスとユーザークラスパスに含まれているクラスファイルと JAR ファイルから必要な情報の一部を収集します。この情報のおかげで dbx は、アプリケーションの実行前にブレークポイントで綿密なエラー検査を行うことができます。

一部 Java クラスとその属性に、クラスパスからアクセスできないことがあります。dbx はそうしたクラスを調べて、ステップ実行することができ、式パーサーはそれらが読み込まれてからアクセスできるようになります。ただし、dbx が収集する情報は一時的な情報であり、JVM ソフトウェアが終了すると利用できなくなります。

Java アプリケーションのデバッグに dbx が必要とする情報はどこにも記録されません。このため dbx は、Java のソースファイルを読み取り、コードをデバッグしながらその情報を取得しようとします。

構文と機能が Java モードとネイティブモードで完全に同じコマンド

ここでは、構文と行う処理が Java モードとネイティブモードで完全に同じ dbx コマンドをまとめています。

Java モードで構文が異なる dbx コマンド

ここでは、Java のデバッグとネイティブコードのデバッグで構文が異なる dbx コマンドをまとめています。これらのコマンドは、Java モードとネイティブモードで動作が異なります。

Java モードでのみ有効なコマンド

ここでは、Java または JNI モードでのみ有効な dbx コマンドをまとめています。