-
How do I correctly mount a Source Path(s)?
Use the File | Mount Source Path... menu item to select
a Source Path directory so that JDebugTool can find your source code.
A Source Path is a parent directory containing your Java packages (and source files)
and is set analogously to a CLASSPATH directory.
JDebugTool assumes that the directory structure matches the package hierarchy.
For example, if the source file corresponding to class mypackage.MyClass
(class MyClass in package mypackage)
is located in the file c:/myjavafiles/mypackage/MyClass.java, then the
correct Source Path would be c:/myjavafiles
Note that a Source Path does not include any package names.
You can also just type the full path name of the Source Path directory
(for example: c:/myjavafiles) in the File name text field and then
click on the Mount (Open) button.
Note that you can mount multiple Source Paths.
-
Why am I getting a "missing tools.jar" error message on starting JDebugTool?
Make sure you invoked JDebugTool by explicitly typing
jdkx.x/bin/java -jar jdebugtool.jar
(Note that just typing java
invokes the wrong java, you must use the JDK java, not the JRE java command).
Make sure that you copied
jdkx.x/lib/tools.jar into
jdkx.x/jre/lib/ext/tools.jar
Note that JDebugTool will provide the instructions for manually copying the tools.jar file,
if missing.
-
Why am I getting an "Unable to access jarfile" or "java.util.zip.ZipException"
when trying to invoke JDebugTool?
This is because the java -jar command can not find jdebugtool.jar.
You need to explicitly give the path to the jar, for example:
jdkx.x/bin/java -jar /home/example/jdebugtool.jar
-
What is the most direct way to set a breakpoint?
To directly set/clear a breakpoint, click on the leftmost column on the appropriate line in a Source Window.
To directly enable/disable a breakpoint, hold down the Ctrl key and click on the leftmost column
on the appropriate line (that already has a breakpoint set) in a Source Window.
-
How do I directly set a method breakpoint?
Highlight the method name (including method arguments, if an overloaded method name)
in the Source Window and select the Set Method Breakpoint menu item
from the right-click popup menu.
Method breakpoints are visually indicated in the line number column at the same
line as the corresponding method signature in the source code display,
when the breakpoint is set by the user, if the method breakpoint can be resolved
by parsing the source code.
-
How do I drill down to view an object's fields?
Double click (or select Inspect... from the right-click popup menu) on any object reference
displayed in a table in JDebugTool. Or highlight an object reference in the current scope
in the Source Window and click on the Magnifying Glass
button in the toolbar (or select Inspect... from the right-click popup menu).
The object's fields will be displayed in a popup dialog.
-
How do I stop when a certain exception is thrown?
For JDebugTool to catch a thrown exception, select the Exceptions | Catch... menu item,
from the menubar.
-
How do I set a watch?
A watch is a simple expression to evaluate when the target is stopped in the
debugger according to the current context. JDebugTool support two tables of
watches -- Watch Panel 1 and Watch Panel 2.
To set a watch, select a local variable displayed in the Locals Panel table or select an object field
displayed in the This Panel table, and then select the Watch Panel 1 or
Watch Panel 2 menu item from the
right-click popup menu. Or highlight a variable name in a Source Window and then select the
Watch Panel 1 or Watch Panel 2 menu item from the right-click popup menu.
Or select Add Panel 1... or Add Panel 2... from the Watches menu
in the menubar. Then enter an expression in the resulting New Watch Dialog and finally
click on the OK button.
-
How do I set a watchpoint?
A watchpoint stops execution of the target in the debugger when a object field
is accessed (read) or modified (written)
and optionally according to certain constraints on the value of the field.
To set a watchpoint, select an object field displayed in a table in JDebugTool, and then select the Watchpoint...
menu item from the right-click popup menu. Or drill down and select a class field in the loaded Classes Panel tree,
and select the Watchpoint... menu item from the right-click popup menu.
The Set Watchpoint Dialog will then be displayed, where you can enter your constraints
followed by clicking on the OK button.
-
How do I stop on Thread Start and/or Thread Death events?
In the Threads Panel, select the Events... menu item from the right-click
popup menu. The Set Thread Events Dialog will then be displayed, where you can
enter your constraints followed by clicking on the OK button.
-
How do I stop on Class Prepare and/or Class Unload events?
In the Loaded Classes Panel, select the Events... menu item from the right-click
popup menu. The Set Class Events Dialog will then be displayed, where you can
enter your constraints followed by clicking on the OK button.
-
How do I stop on Method Entry and/or Method Exit events?
In the Threads Panel, check the Method Entry Events checkbox and/or Method Exit Events
checkbox for the appropriate thread(s).
-
JDebugTool does not stop at the main() breakpoint, or does not
display my local variables or method arguments.
You must compile your source code with the -g option
[for Sun's javac] in order for the compiler to generate debugging information.
-
How do I prevent JDebugTool from stepping into 3rd party packages and trying to
display 3rd party source code that I am not interested in?
Use the Execution | Excludes... menu item from the menubar,
and the resulting Stepping Excludes Dialog.
-
How do I change the value of a primitive variable?
Double click on the value of a primitive (boolean, byte, character, short, int,
long, float or double) variable displayed in a table in the GUI;
enter the new value followed by hitting the Enter key
(hitting the Escape key will cancel the editing).
-
How do I set/edit breakpoint groups?
Double click on a cell in the Group column in the Breakpoints Panel;
enter the new group name followed by hitting the Enter key (hitting the Escape key
will cancel the editing). If the Group column
is not displayed, select the Columns... menu item from the right click popup menu
in the Breakpoints Panel.
To clear or disable/enable all the breakpoints in
a group, see the Breakpoints menu in the menubar.
-
How do I invoke the target JVM so that JDebugTool can then attach to or listen for
the target JVM?
See JDebugTool's Context sensitive Help Viewer for many examples. For the official documentation from
Sun, see the JPDA Connection and Invocation Details for
JDK 1.6,
JDK 1.5,
JDK 1.4 or
JDK 1.3.
For JDebugTool to attach to the target, use the Target | Attach... menu item
from the menubar, and the resulting Attach Dialog. For JDebugTool to listen for a connection from the
target, use the Target | Listen menu item from the menubar, and the resulting Listen Dialog.
See also the JDebugTool Tutorial.
See also FAQ #25
How do I debug an Apache Tomcat 5.0 Servlet?
-
How do I debug an Applet?
Basically you need to attach (see the Target | Attach... menu
item from the menubar, and the resulting Attach Dialog) to the Java Plugin.
See Applet Debugging Support from Sun, for
JDK 1.6,
JDK 1.5 or
JDK 1.4,
on how to configure the Java Plugin to support debugging (and being attached to by JDebugTool).
-
How do I debug a Java Web Start Application?
The following was originally posted by mswanson as FYI: great debugging solution in Sun's
Java Web Start and JNLP forum, for JDK 1.4:
I would like to let the JWS community know of a great way to debug your JWS app.
Solutions have been posted before but I haven't seen anything as easy as this:
Create your own bin/java wrapper like this:
(NOTE: This is Linux/Solaris specific - a Win32 bat file would work the same way
but perhaps with %1 %2 %3 %4... instead of $*). Anyone care to try a .bat version?
#!/bin/bash
# $Id: myjava,v 1.3 2003/03/06 05:13:23 mswanson Exp $
# Exists so we can debug ScheduleWorld
#
${JDK}/bin/java -Xdebug -Xnoagent -Djava.compiler=NONE
-Xrunjdwp:transport=dt_socket,server=y,address=8118,suspend=n $*
Modify 8118 to whatever port you want to use.
Download JDebugTool from www.debugtools.com
(optional) create an alias to save yourself some time starting your app.
alias sw='${JAVAWS} http://localhost/sw/ScheduleWorldLocalhost.jnlp'
Start 'javaws' and change your JVM to point to your shell script (or bat file)
NOTE: you may want to do this from a separate account so that your main account
won't require the debugger to run any JWS apps... :-)
Start your app
NOTE: with the alias you can just type 'sw' in a shell.
alt-tab to JDebugTool, attach to your running JWS app (ALT-T, A, Enter)
You will see the usual splash screen, version check, and the VM will exit.
Don't panic.
Attach to your running JWS app again.
This step was necessary as JWS seems to spawn a totally new JVM after dealing with
the jnlp.
Debug away. Note that with the use of POP_STACK and HOT_SWAP you can skip
steps 1-9 even though you have modified and recompiled your code. This takes some
setting up (source paths) which I will leave to the JDebugTool docs.
Many of you have probably been HOT_SWAP'ing classes inside a running JVM for
some time and know what an absolute time saver this can be. If you haven't,
it is highly likely that your GUI development will be up (at least) a notch
by using HOT_SWAP and (less often) POP_STACK. Speaking from experience, it has
save me an _enormous_ amount of time.
-
How do I debug a JSP (Java Server Pages)?
You can indirectly debug a JSP by saving the generated Java source code of the JSP
and mounting the generated Java source code in JDebugTool (see
FAQ #1).
See also FAQ #26
How do I debug an Apache Tomcat 5.0 JSP?
-
How do I Hot Swap a class?
Hot Swap (fix a bug, reload the class, and continue) is a feature of JDK 1.4 or later.
Select a class in the Classes Tree Panel and then select Hot Swap...
from the right click popup menu, or select Hot Swap... from the right click popup
menu in the Source Window to Hot Swap the class corresponding to the currently
viewed source file. Check the Target Info Dialog to see
if your target JVM supports Hot Swap. Note that methods currently being executing before
the Hot Swap will continue to execute with the old code. New method invocations after
the Hot Swap will execute with the newly defined code. See also FAQ #22.
-
How do I Pop a stack frame?
Popping a stack frame(s) is a feature of JDK 1.4 or later.
Select the Pop... menu item in the Stack menu in the menubar.
Check the Target Info Dialog to see if your target JVM supports
Can pop frames. This feature is useful for re-executing a
method(s) particularly those that are to be Hot Swapped.
You can Pop a method, Hot Swap the corresponding class, and then
Step In and re-execute the fixed method code.
-
Why do Swing GUI applications (including JDebugTool) hang?
Java Swing GUI applications (including JDebugTool) can hang.
The work around is to add the following argument to java -Dsun.java2d.noddraw=true
-
Why do Swing GUI applications (including JDebugTool) crash or hang my Operating System?
Java Swing GUI applications (including JDebugTool) can exercise bugs in some video device drivers that can crash
or hang your Operating System. Make sure you are using the most current version of Java
and also update your video device driver for your Operating System for bug fixes.
Also try adding the following argument to java -Dsun.java2d.d3d=false
-
How do I debug an Apache Tomcat 5.0 Servlet?
First make sure you have defined the environment variable JAVA_HOME to point to
the root directory where you have the JDK installed. Then simply invoke on Windows
$CATALINA_HOME/bin/catalina.bat jpda start
or on Unix
$CATALINA_HOME/bin/catalina.sh jpda start
Then in JDebugTool, select Attach... from the Target menu in the menubar, to display the
Attach to Target dialog. On Windows, select the Shared Memory tab, and enter
jdbconn in the Shared Memory Name field. On Unix, select the
Socket tab, and enter 8000 in the Port Number field. If you are debugging
Tomcat remotely (on a different computer) also enter the Host Name field with
the hostname or IP address of the computer where Tomcat is running.
Note that the above defaults of jdbconn on Windows, and 8000
on Unix can be changed by defining the JPDA_ADDRESS environment variable.
Also the default transport of dt_shmem on Windows, and dt_socket
on Unix can be changed by defining the JPDA_TRANSPORT environment variable.
Finally click on the OK button in the Attach to Target dialog in JDebugTool.
You should now be attached to Tomcat, and ready to debug.
-
How do I debug an Apache Tomcat 5.0 JSP?
You can indirectly debug a Tomcat 5.0 JSP, by generating the corresponding
Java source file, and then Mounting the corresponding Source Path in
JDebugTool.
First you will need to attach JDebugTool to Tomcat as described in
FAQ #25 above. Then you will need to
invoke your JSP to determine where the generated Java source file is created.
For example, you would then Mount the following Source Path (see
FAQ #1):
$CATALINA_HOME/webapps/mywebapp/WEB-INF/classes
where mywebapp would be the corresponding name of your web app.
You are now ready to debug the generated Java source file as usual.
-
Why are my breakpoints in inner classes not being hit?
First make sure you have correctly specified the version of the Java compiler that was
used to compile your project's source code. Select the Project Settings...
menu item from the Edit menu in JDebugTool's main menubar.
JDebugTool figures out the inner class name to set the breakpoint in
by parsing your source code file. If the breakpoint is not being hit, then
JDebugTool maybe generating the wrong inner class name. You can see the class name
that JDebugTool heuristically generated, by examining the corresponding breakpoint row in the
Breakpoints Panel, and looking at the Class column (the tool tip will show the
complete, expanded class name). Also look at the message in the Resolved column
(see the JDebugTool Breakpoints Panel context-sensitive help for more details).
The correct class name to use for the breakpoint, depends on which version of the
JDK and corresponding compiler you are using. We currently support Sun's javac.
If you think that JDebugTool is generating the wrong class name, then examine the following:
Inspect the Navigator Panel to see if JDebugTool is parsing your source
code correctly, to determine the class (including inner class) structure and
corresponding methods of your source file. A tool tip on a class or inner class
tree node, will display the corresponding generated full class name.
By examining the names of the corresponding .class files that your compiler generates, you
may be able figure out the correct class name for the breakpoint. Also by inspecting
the classes displayed in the Loaded Classes Panel, you may also be able to
determine the correct class name for the breakpoint.
If you think that
JDebugTool is generating the wrong class name for the breakpoint, you can
prove this by manually creating the breakpoint in JDebugTool, by selecting Set... from the
Breakpoints menu in the menubar. In the resulting Set Breakpoint dialog, you can
then enter the correct Java Class and Line Number parameters,
followed by clicking the OK button. If the entered parameters are correct, then
JDebugTool should hit the corresponding breakpoint.
-
Will JDebugTool work correctly if the same class is loaded multiple times
(by multiple ClassLoaders) into the target JVM?
JDebugTool assumes that there is only a single class by a given name loaded
into the target JVM. If the same class is loaded multiple times (by multiple
ClassLoaders) into the target JVM, then debugging will not work correctly
for those classes. For debugging purposes, change your application configuration
so that this is not the case.
For the Hot Swap feature, if there are multiple classes by the same name loaded
(by multiple ClassLoaders) into the target JVM, Hot Swap will try to
Hot Swap all of them, after confirmation by the user. The number of classes
successfully Hot Swapped, will then be reported.
-
How do I prevent JDebugTool from stopping at uncaught thrown exceptions
in the target JVM?
By default, JDebugTool will stop at any thrown exceptions that are not caught
by the target program. To prevent this, if desired, disable the
(All Uncaught Exceptions) first table row (by clicking on the E checkbox)
in the Exceptions Panel in the debugger.
You can also right-click on the (All Uncaught Exceptions)
first table row in the Exceptions Panel and select Edit...from the resulting
pop up context menu, to display the Catch Exception Dialog, in order to edit the
properties of (All Uncaught Exceptions).
Use the Include Classes or the Exclude Classes fields to filter out
uncaught exceptions when thrown from locations that you are not interested in.
-
I have specified a Java exception to be caught in the debugger.
How do I filter out this exception when thrown from locations that I am not interested in?
Right-click on a user specified exception to be caught in the debugger in the
Exceptions Panel and select Edit... from the resulting pop up context menu,
to display the Catch Exception Dialog,
in order to edit the properties of the exception.
Use the Include Classes or the Exclude Classes fields to filter out the
exception when thrown from locations that you are not interested in. These
filters can also be specified when initially creating the exception to catch
in the debugger.
