You can use dbx to debug the following types of Java applications:
A file with a file name that ends in .class
A file with a file name that ends in .jar
A Java application that is started using a wrapper
A running Java application that was started in debug mode to which you attach dbx
A C application or C++ application that embeds a Java application using the JNI_CreateJavaVM interface
dbx recognizes that it is debugging a Java application in all of these cases.
You can debug a file that uses the .class file name extension using dbx as in the following example.
(dbx) debug myclass.class |
If the class that defines the application is defined in a package, you need to include the package path just as when running the application under the JVM software, as in the following example.
(dbx) debug java.pkg.Toy.class |
You can also use a full path name for the class file. dbx automatically determines the package portion of the class path by looking in the .class file and adds the remaining portion of the full path name to the class path. For example, given the following path name, dbx determines that pkg/Toy.class is the main class name and adds /home/user/java to the class path.
(dbx) debug /home/user/java/pkg/Toy.class |
A Java application can be bundled in a JAR (Java Archive) file. You can debug a JAR file using dbx as in the following example.
(dbx) debug myjar.jar |
When you start debugging a file that has a file name ending in .jar, dbx uses the Main_Class attribute specified in the manifest of this JAR file to determine the main class. (The main class is the class within the JAR file that is your application’s entry point. If you use a full path name or relative path name to specify the JAR file, dbx uses the directory name and prefixes it to the class path in the Main-Class attribute.
If you debug a JAR file that does not have the Main-Class attribute, you can use the JAR URL syntax jar:<url>!/{entry} that is specified in the class JarURLConnection of the Java 2 Platform, Standard Edition to specify the name of the main class, as in the following examples.
(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 |
For each of these examples dbx would do the following:
Treat the class path specified after the ! character as the main class (for example, /myclass.class or /x/y/z.class)
Add the name of the JAR file ./myjar.jar, /a/b/c/d/e.jar, or /a/b/c/d.jar to the class path
Begin debugging the main class
If you have specified a custom startup of the JVM software using the jvm_invocation environment variable (see Customizing Startup of the JVM Software), the file name of the JAR file is not automatically added to the class path. In this case, you must add the file name of the JAR file to the class path when you start debugging.
A Java application usually has a wrapper to set environment variables. If your Java application has a wrapper, you need to tell dbx that a wrapper script is being used by setting the jvm_invocation environment variable (see Customizing Startup of the JVM Software).
You can attach dbx to a running Java application if you specified the options shown in the following example when you started the application. After starting the application, you would use the dbx command (see dbx Command) with the process ID of the running Java process to start debugging.
$ java -Djava.compiler=NONE -Xdebug -Xnoagent -Xrundbx_agent myclass.class $ dbx - 2345 |
For the JVM software to locate libdbx_agent.so, you need to add the appropriate path to LD_LIBRARY_PATH before running the Java application:
If you are using the 32-bit version of the JVM software on a system running the Solaris OS, add /installation_directory/SUNWspro/lib/libdbx_agent.so
If you are using the 64-bit version of the JVM software on a SPARC based system running the Solaris OS, add /installation_directory/SUNWspro/lib/v9/libdbx_agent.so to LD_LIBRARY_PATH.
If you are using the 64-bit version of the JVM software on an x64 based system running the Linux OS, add/installation_directory/sunstudio12/lib/amd64/libdbx_agent.so to LD_LIBRARY_PATH.
The installation_directory is the location where the Sun Studio software is installed.
When you attach dbx to the running application, dbx starts debugging the application in Java mode.
If your Java application requires 64-bit object libraries, include the -d64 option when you start the application. Then when you attach dbx to the application, dbx will use the 64-bit JVM software on which the application is running.
$ java -Djava.compiler=NONE -Xdebug -Xnoagent -Xrundbx_agent -d64 myclass.class $ dbx - 2345 |
You can debug a C application or C++ application that embeds a Java application using the JNI_CreateJavaVM interface. The C application or C++ application must start the Java application by specifying the following options to the JVM software:
-Xdebug -Xnoagent -Xrundbx_agent |
For the JVM software to locate libdbx_agent.so, you need to add the appropriate path to LD_LIBRARY_PATH before running the Java application:
If you are using the 32-bit version of the JVM software on a system running the Solaris OS, add/installation_directory/SUNWspro/lib/libdbx_agent.so to LD_LIBRARY_PATH.
If you are using the 64-bit version of the JVM software on a SPARC based system running the Solaris OS, add /installation_directory/SUNWspro/lib/v9/libdbx_agent.so to LD_LIBRARY_PATH.
If you are using the 64-bit version of the JVM software on an x64 based system running the Linux OS, add /installation_directory/sunstudio12/lib/amd64/libdbx_agent.so to LD_LIBRARY_PATH.
The installation_directory is the location where the Sun Studio software is installed.
When you use the run command in Java mode, the arguments you give are passed to the application and not to the JVM software. To pass arguments to the JVM software, see Customizing Startup of the JVM Software.
Sometimes your Java source files are not in the same directory as the .class or .jar files. You can use the $JAVASRCPATH environment variable to specify the directories in which dbx should look for Java source files. For example JAVASRCPATH=.:/mydir/mysrc:/mydir/mylibsrc:/mydir/myutils causes dbx to look in the listed directories for source files that correspond to the class files being debugged.
dbx might not be able to find your C source files or C++ source files in the following circumstances:
If your source files are not in the same location as they were when you compiled them
If you compiled your source files on a different system than the one on which you are running dbx and the compile directory does not have the same path name
In such cases, use the pathmap command (see pathmap Command) to map one path name to another so that dbx can find your files.
An application can have custom class loaders that load class files from locations that might not be part of the regular class path. In such situations dbx cannot locate the class files. The CLASSPATHX environment variable lets you specify to dbx a path for the class files that are loaded by their custom class loaders. For example, CLASSPATHX=.:/myloader/myclass:/mydir/mycustom causes dbx to look in the listed directories when it is trying to locate a class file.
To set a stop breakpoint on a Java method in a class file that has not been loaded by the JVM software, use the full name of the class with a stop in command, or the class name with a stop inmethod command. See the following example.
(dbx) stop in Java.Pkg.Toy.myclass.class.mymethod (dbx) stop inmethod myclass.class.mymethod |
To set a stop breakpoint on a C function or C++ function in a shared library that has not been loaded by the JVM software, preload the symbol table of the shared library before setting the breakpoint. For example, if you have a library named mylibrary.so that contains a function named myfunc, you could preload the library and set a breakpoint on the function as follows:
(dbx) loadobject -load fullpathto/mylibrary.so (dbx> stop in myfunc |
You can also load the symbol tables of all dynamically loaded shared objects by running your application once before beginning to debug it with dbx.