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 |
Java アプリケーションは、JAR (Java Archive) ファイルにバンドルすることができます。JAR ファイルは、次の例に示すように dbxを使用することによってデバッグすることができます。
(dbx) debug myjar.jar |
ファイル名が .jar で終わるファイルのデバッグを開始すると、dbx は、その JAR ファイルのマニフェストに指定されている Main_Class 属性を使って主クラスを特定します (主クラスは、アプリケーションのエントリポイントになっている、JAR ファイル内のクラスです)。フルパス名または相対パス名を使って JAR ファイルが指定された場合、dbx は Main-Class 属性のクラスパスの前にそのディレクトリ名を追加します。
JAR ファイルに Main-Class 属性がない場合は、次の例に示すように Java 2 Platform, Standard Edition の JarURLConnection クラスに指定されている JAR の URL 構文、jar:<url>!/{entry} を使って、主クラスの名前を指定することができます。
(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 アプリケーションにラッパーがある場合は、jvm_invocation 環境変数を設定することによって、ラッパースクリプトを使用することを dbx に知らせる必要があります (「JVM ソフトウェアの起動方法のカスタマイズ」を参照)。
Java アプリケーションを起動するときに次の例に示すオプションを指定することによって、動作中の Java アプリケーションに dbx を接続することができます。アプリケーションが起動すると、動作中のプロセスのプロセス ID を指定して dbx コマンドを実行することによって、デバッグを開始することができます (「dbx コマンド」を参照)。
$ java -Djava.compiler=NONE -Xdebug -Xnoagent -Xrundbx_agent myclass.class $ dbx - 2345 |
JVM ソフトウェアが libdbx_agent.so を見つけられるようにするには、Java アプリケーションを実行する前に正しいパスを LD_LIBRARY_PATH に追加する必要があります。
SolarisOS を実行しているシステムで 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 は Sun Studio ソフトウェアがインストールされている場所です。
動作中のアプリケーションに dbx を接続すると、dbx は Java モードでアプリケーションのデバッグを開始します。
Java アプリケーションが 64 ビットのオブジェクトライブラリを必要とする場合は、アプリケーションを起動するときに -d64 オプションを追加してください。この場合、dbx はアプリケーションが動作している 64 ビットの JVM ソフトウェアを使用します。
$ java -Djava.compiler=NONE -Xdebug -Xnoagent -Xrundbx_agent -d64 myclass.class $ dbx - 2345 |
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 は Sun Studio ソフトウェアがインストールされている場所です。
Java モードで run コマンドを使用した場合、指定した引数は、JVM ソフトウェアではなく、アプリケーションに渡されます。 JVM ソフトウェアに引数を渡す方法については、「JVM ソフトウェアの起動方法のカスタマイズ」を参照してください。
Java ソースファイルが、.class や .jar ファイルと異なるディレクトリに置かれていることがあります。その場合は、$JAVASRCPATH 環境変数を使って、dbx が Java ソースファイルを探すディレクトリを指定することができます。たとえば JAVASRCPATH=.:/mydir/mysrc:/mydir/mylibsrc:/mydir/myutils の場合、dbx は指定されたディレクトリで、デバッグ対象のクラスファイルに対応するソースファイルを探します。
次の場合は、dbx が C/C++ ソースファイルを見つけられないことがあります。
ソースファイルの現在の格納場所がコンパイルしたときにあった場所と異なる場合
dbx を実行しているシステムとは異なるシステムでソースファイルをコンパイルし、コンパイルディレクトリのパス名が異なる場合
このような場合、dbx がファイルを見つけられるよう、pathmap コマンドを使ってパス名を別のパス名に対応づけてください (「pathmap コマンド」を参照)。
通常のクラスパスに含まれてない場所からクラスファイルを読み込む独自のクラスローダーが、アプリケーションに存在することがあります。そのような場合、dbx はクラスファイルを見つけられません。CLASSPATHX 環境変数を使って、独自のクラスローダーが読み込む Java クラスファイルのパスを指定することができます。たとえば CLASSPATHX=.:/myloader/myclass:/mydir/mycustom の場合、dbx は指定されたディレクトリでクラスファイルを探そうとします。
JVM ソフトウェアによって読み込まれていないクラスファイル内の Java メソッドに停止ブレークポイントを設定するには、stop in コマンドでクラスのフル名を使用するか、stop inmethod コマンドでクラス名を使用します。次はその例です。
(dbx) stop in Java.Pkg.Toy.myclass.class.mymethod (dbx) stop inmethod myclass.class.mymethod |
JVM ソフトウェアによって読み込まれていない共有ライブラリ内の C/C++ 関数に停止ブレークポイントを設定するには、ブレークポイントを設定する前に共有ライブラリのシンボルテーブルを事前に読み込みます。たとえば myfunc という関数を含む mylibrary.so というライブラリがある場合は、次のように入力することによって、ライブラリを事前に読み込み、関数にブレークポイントを設定することができます。
(dbx) loadobject -load fullpathto/mylibrary.so (dbx> stop in myfunc |
dbx でデバッグを開始する前に 1 回アプリケーションを実行することによって、動的に読み込まれたすべての共有オブジェクトのシンボルテーブルを読み込むこともできます。