-
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.
JDebugTool can automatically detect and fix incorrectly mounted source paths.
In the Source Tree panel, under an incorrectly
mounted source path, click on a Java source file in order to display the file.
JDebugTool will then automatically unmount the incorrect source path, and then
automatically mount the corresponding correct source path, after prompting the
user.
Note that you can mount multiple Source Paths for each independent
source tree hierarchy.
-
Why am I getting dialog entitled JDebugTool Instructions when trying
to debug (Run/Attach/Listen) a target JVM?
This is because you did not invoke JDebugTool itself correctly.
In order to debug a target JVM, JDebugTool needs access to the
Java Debugger Interface found in the JDK tools.jar file (so make sure that you
typed the path to tools.jar correctly).
See Step 5. Invoking JDebugTool in the
Tutorial.
-
Why am I getting a "java.lang.NoClassDefFoundError
com/debugtools/jdebugtool/Main"
exception when trying to invoke JDebugTool?
This is because you do not invoke JDebugTool itself correctly.
Either the jdebugtool.jar file can not be found (so make sure that you typed the path to
jdebugtool.jar correctly) or you did not type "com.debugtools.jdebugtool.Main"
correctly. See Step 5. Invoking JDebugTool in the
Tutorial.
-
What is the most direct way to set a breakpoint?
To directly set/clear a breakpoint, click on the line number column on the appropriate line in a Source Window.
To directly enable/disable a breakpoint, hold down the Ctrl key and click on the line number column
on the appropriate line (that already has a breakpoint set) in a Source Window.
-
How do I directly set a method breakpoint?
To create a breakpoint when a particular method is called, navigate to the
method body in the source code. Click to place the blinking cursor anywhere
on the same line as the method name in the method signature, and then select
Set Method Breakpoint from the right-click pop-up 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 click 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 window.
The same procedures are also used for drilling down into array and
string references.
Hover the mouse over an object reference (including array and
string references) displayed in the GUI in the current scope, to display
a multi-line tool tip showing the contents of the object.
-
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 supports 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 Add to Watch Panel 1 or
Add to Watch Panel 2 menu item from the
right-click popup menu. Or click on a variable name in the current scope in the
Source Window and then select the Add to Watch Panel 1 or
Add to Watch Panel 2 menu item from the right-click popup menu.
Or select Add to Watch Panel 1... or Add to Watch 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 JVM in the debugger when a field
is accessed (read) or modified (written)
and optionally according to certain constraints on the value of the field.
To set a watchpoint, select a 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 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, or I cannot successfully set/hit
breakpoints.
You must compile your source code with the -g option
[for Sun's javac] in order for the compiler to generate debugging information,
for example:
javac -g *.java
See also FAQ #37: Why are breakpoints not being hit in
the debugger?
-
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 whose source code contains the
blinking cursor in 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?
Yes, as of JDebugTool 4.4.3. The debugger supports breakpoints, exceptions, and
watchpoints when the same class is loaded multiple times (by multiple
ClassLoaders) into the target JVM. The Resolved column (and corresponding
tool tips), gives ClassLoader aware feedback in the Breakpoints, Exceptions,
and Watchpoints panels (select Columns... from the right-click pop-up menu).
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 (and corresponding ClassLoaders), 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.
-
How do I select the Look and Feel, and also the font size of the GUI?
See Global Settings (Edit | Global Settings...).
-
How do I define and launch an external text editor?
A user definable external text editor can be specified in the Global Settings
(Edit | Global Settings...) in the Source tab. To launch the
external text editor on the currently displayed Java source file, select
File | External Editor....
-
How do I persistently save debugger settings into projects?
See the Project Manager (File | Project Manager...).
There is always a default project, if you do not want to create any projects.
-
How do I debug multiple JVM processes simultaneously in JDebugTool?
For each target JVM process that you want to debug, invoke a corresponding
JDebugTool instance. In each JDebugTool instance, create a project
(File | Project Manager...) corresponding
to each target JVM process. Then in each JDebugTool instance, connect to (see the
Target menu and the Tutorial) and
debug each corresponding target JVM process.
-
How do I launch JDebugTool as an external tool in Eclipse?
The following instructions augment the JDebugTool Tutorial,
with information on how to quickly launch JDebugTool as an external tool in Eclipse.
In the Eclipse toolbar, click on the External Tools drop-down menu button,
and select the External Tools Configurations... menu item.
In the resulting External Tools Configurations dialog, click on Program
in the tree on the left-hand side. Then click on the New launch configuration
button in the dialog's toolbar.
In the resulting form page, type JDebugTool in the Name field.
In the Main tab, in the Location field, click on the
Browse File System... button. In the resulting File Selection dialog,
select the location of the JDK Java executable you will use to launch JDebugTool.
For example:
c:/Program Files/Java/jdk1.6.0_18/bin/java.exe
In the Main tab, in the Arguments field, type the arguments
required to launch JDebugTool. For example:
-cp "c:/Users/Mike/jdebugtool/jdebugtool.jar;
c:/Program Files/Java/jdk1.6.0_18/lib/tools.jar"
com.debugtools.jdebugtool.Main
Note that there is no space after the semicolon. On UNIX®
use a colon instead of the semicolon as the classpath separator.
An optional JDebugTool project name may be specified as the last
argument, in order for the debugger to open a specific project.
If you name your
JDebugTool project the same name as your Eclipse project, then you can click on the
Variables... button under the Arguments field.
In the resulting Select Variable dialog, select
project_name from the list and then click on the OK button to insert the argument
${project_name} as the last argument in the Arguments field.
Then eclipse will substitute the currently selected Eclipse project name
(in the Package Explorer) as the last argument, when launching JDebugTool.
Finally click on the Apply button in the External Tools Configurations
dialog to save your settings. Then click on the Run button to test launch JDebugTool.
Now you will be able to quickly launch JDebugTool from Eclipse by clicking
on the External Tools drop-down menu button in the Eclipse toolbar
and selecting the JDebugTool menu item.
Assuming the default Eclipse project layout, you would Mount the following
Source Path in JDebugTool. For example:
c:/Users/Mike/workspace/MyProject/src
Assuming the default Eclipse project layout, you would add the following
CLASSPATH entry in the Run In Debugger dialog in JDebugTool. For example:
c:/Users/Mike/workspace/MyProject/bin
- In Eclipse, make sure that Generate Debugging Info is turned on
(which it is by default), by right-clicking on your Eclipse project and selecting
Properties from the resulting pop-up context menu. In the resulting
Properties dialog, click on Java Compiler in the left-hand side list.
In the resulting form, under
Classfile Generation, make sure that the following check boxes are checked:
- Add variable attributes to generated class files (used by the
debugger)
- Add line number attributes to generated class files
(used by the debugger)
- Add source file name to generated
class file (used by the debugger)
-
How do I debug a NetBeans project in JDebugTool?
The following instructions augment the JDebugTool Tutorial,
with information on how to debug a NetBeans project in JDebugTool.
Assuming the default NetBeans project layout, you would Mount the following
Source Path in JDebugTool. For example:
c:/Users/Mike/projects/MyProject/src
Assuming the default NetBeans project layout, you would add the following
CLASSPATH entry in the Run In Debugger dialog in JDebugTool. For example:
c:/Users/Mike/projects/MyProject/build/classes
In NetBeans, make sure that Generate Debugging Info is turned on
(which it is by default), by right-clicking on your NetBeans project and selecting
Properties from the resulting pop-up context menu. In the resulting
Project Properties dialog, click on Compiling under Build,
in the Categories tree. In the resulting form, make sure that the
Generate Debugging Info checkbox is checked.
-
Why are breakpoints not being hit in the debugger?
JDebugTool can tell you whether a breakpoint should be hit or not, when connected
to a target JVM, once the corresponding class should have been loaded:
Right-click on the Breakpoints Panel, and select Columns...from the resulting pop up
menu. Then select the Resolved checkbox, and click OK. Now the Resolved column
(and corresponding tool tips) in the Breakpoints Panel will give you feedback
about each breakpoint:
Whether the breakpoint is currently resolved (the corresponding source file name and
line number displayed in green) or unresolved (displayed in orange). A breakpoint is
resolved if the class containing the breakpoint has been loaded into the target JVM.
If it is determined that a breakpoint is invalid when it gets resolved, the corresponding
error message will be displayed in red.
See also:
- FAQ #13: JDebugTool does not stop at the main()
breakpoint, or does not display my local variables or method arguments, or I
cannot successfully set/hit breakpoints.
- FAQ #27: Why are my breakpoints in inner classes
not being hit?
- FAQ #28: Will JDebugTool work correctly if the same
class is loaded multiple times (by multiple ClassLoaders) into the target JVM?
-
What is JDebugTool's debugging thread model?
When the target JVM is suspended (such as hitting a breakpoint, catching
an exception in the debugger, hitting a watchpoint, stopping on a thread
start/death, class prepare/unload or method entry/exit debugging event, or
clicking on the Suspend All button), all threads in the target JVM are
suspended.
When the target JVM is resumed (such as single stepping, or clicking on the
Resume All or Run to Cursor buttons), all threads in the target JVM are resumed.
When the target JVM is suspended, you can switch the debugging context between
threads, by clicking on a thread in the Threads panel.
