1jdb(1) General Commands Manual jdb(1)
2
6 jdb - The Java Debugger
7 jdb helps you find and fix bugs in Java language programs.
9
11 jdb [ options ] [ class ] [ arguments ]
12 options
15 Command-line options, as specified below.
16 class
18 Name of the class to begin debugging.
19 arguments
21 Arguments passed to the main() method of class.
22
25 The Java Debugger, jdb, is a simple command-line debugger for Java
26 classes. It is a demonstration of the Java Platform Debugger Architec‐
27 ture @
28 http://docs.oracle.com/javase/7/docs/technotes/guides/jpda/index.html
29 that provides inspection and debugging of a local or remote Java Vir‐
30 tual Machine.
31 Starting a jdb Session
33 There are many ways to start a jdb session. The most frequently used
34 way is to have jdb launch a new Java Virtual Machine (VM) with the main
35 class of the application to be debugged. This is done by substituting
36 the command jdb for java in the command line. For example, if your
37 application's main class is MyClass, you use the following command to
38 debug it under JDB:
39 % jdb MyClass
41 When started this way, jdb invokes a second Java VM with any specified
44 parameters, loads the specified class, and stops the VM before execut‐
45 ing that class's first instruction.
46 Another way to use jdb is by attaching it to a Java VM that is already
48 running. Syntax for Starting a VM to which jdb will attach when the VM
49 is running is as follows. This loads in-process debugging libraries and
50 specifies the kind of connection to be made.
51 -agentlib:jdwp=transport=dt_socket,server=y,suspend=n
53 For example, the following command will run the MyClass application,
56 and allow jdb to connect to it at a later time.
57 % java -agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=n MyClass
59 You can then attach jdb to the VM with the following commmand:
62 % jdb -attach 8000
64 Note that "MyClass" is not specified in the jdb command line in this
67 case because jdb is connecting to an existing VM instead of launching a
68 new one.
69 There are many other ways to connect the debugger to a VM, and all of
71 them are supported by jdb. The Java Platform Debugger Architecture has
72 additional documentation @
73 http://docs.oracle.com/javase/7/docs/technotes/guides/jpda/conninv.html
74 on these connection options. For information on starting a J2SE 1.4.2
75 or early VM for use with jdb see the 1.4.2 documentation @
76 http://java.sun.com/j2se/1.4.2/docs/guide/jpda/conninv.html
77 Basic jdb Commands
79 The following is a list of the basic jdb commands. The Java debugger
80 supports other commands which you can list using jdb's help command.
81 help, or ?
83 The most important jdb command, help displays the list of recog‐
84 nized commands with a brief description.
85 run
87 After starting jdb, and setting any necessary breakpoints, you
88 can use this command to start the execution the debugged applica‐
89 tion. This command is available only when jdb launches the
90 debugged application (as opposed to attaching to an existing VM).
91 cont
93 Continues execution of the debugged application after a break‐
94 point, exception, or step.
95 print
97 Displays Java objects and primitive values. For variables or
98 fields of primitive types, the actual value is printed. For
99 objects, a short description is printed. See the dump command
100 below for getting more information about an object.
101 NOTE: To display local variables, the containing class must have
102 been compiled with the javac(1) -g option.
103 print supports many simple Java expressions including those with
104 method invocations, for example:
105 o print MyClass.myStaticField
107 o print myObj.myInstanceField
109 o print i + j + k (i, j, k are primities and either fields or
111 local variables)
112 o print myObj.myMethod() (if myMethod returns a non-null)
114 o print new java.lang.String("Hello").length()
116 dump
118 For primitive values, this command is identical to print. For
119 objects, it prints the current value of each field defined in the
120 object. Static and instance fields are included.
121 The dump command supports the same set of expressions as the
122 print command.
123 threads
125 List the threads that are currently running. For each thread, its
126 name and current status are printed, as well as an index that can
127 be used for other commands, for example:
128 4. (java.lang.Thread)0x1 main running
129 In this example, the thread index is 4, the thread is an instance
130 of java.lang.Thread, the thread name is "main", and it is cur‐
131 rently running,
132 thread
134 Select a thread to be the current thread. Many jdb commands are
135 based on the setting of the current thread. The thread is speci‐
136 fied with the thread index described in the threads command
137 above.
138 where
140 where with no arguments dumps the stack of the current thread.
141 where all dumps the stack of all threads in the current thread
142 group. where threadindex dumps the stack of the specified thread.
143 If the current thread is suspended (either through an event such
144 as a breakpoint or through the suspend command), local variables
145 and fields can be displayed with the print and dump commands. The
146 up and down commands select which stack frame is current.
147 Breakpoints
150 Breakpoints can be set in jdb at line numbers or at the first instruc‐
151 tion of a method, for example:
152 o stop at MyClass:22 (sets a breakpoint at the first instruction for
154 line 22 of the source file containing MyClass)
155 o stop in java.lang.String.length (sets a breakpoint at the beginnig
157 of the method java.lang.String.length)
158 o stop in MyClass.<init> (<init> identifies the MyClass constructor)
160 o stop in MyClass.<clinit> (<clinit> identifies the static initial‐
162 ization code for MyClass)
163 If a method is overloaded, you must also specify its argument types so
166 that the proper method can be selected for a breakpoint. For example,
167 "MyClass.myMethod(int,java.lang.String)", or "MyClass.myMethod()".
168 The clear command removes breakpoints using a syntax as in
170 "clear MyClass:45". Using the clear or command with no argument dis‐
171 plays a list of all breakpoints currently set. The cont command contin‐
172 ues execution.
173 Stepping
175 The step commands advances execution to the next line whether it is in
176 the current stack frame or a called method. The next command advances
177 execution to the next line in the current stack frame.
178 Exceptions
180 When an exception occurs for which there isn't a catch statement any‐
181 where in the throwing thread's call stack, the VM normally prints an
182 exception trace and exits. When running under jdb, however, control
183 returns to jdb at the offending throw. You can then use jdb to diagnose
184 the cause of the exception.
185 Use the catch command to cause the debugged application to stop at
187 other thrown exceptions, for example: "catch java.io.FileNotFoundExcep‐
188 tion" or "catch mypackage.BigTroubleException. Any exception which is
189 an instance of the specifield class (or of a subclass) will stop the
190 application at the point where it is thrown.
191 The ignore command negates the effect of a previous catch command.
193 NOTE: The ignore command does not cause the debugged VM to ignore spe‐
195 cific exceptions, only the debugger.
196
198 When you use jdb in place of the Java application launcher on the com‐
199 mand line, jdb accepts many of the same options as the java command,
200 including -D, -classpath, and -X<option>.
201 The following additional options are accepted by jdb:
203 -help
205 Displays a help message.
206 -sourcepath <dir1:dir2:...>
208 Uses the given path in searching for source files in the speci‐
209 fied path. If this option is not specified, the default path of
210 "." is used.
211 -attach <address>
213 Attaches the debugger to previously running VM using the default
214 connection mechanism.
215 -listen <address>
217 Waits for a running VM to connect at the specified address using
218 standard connector.
219 -listenany
221 Waits for a running VM to connect at any available address using
222 standard connector.
223 -launch
225 Launches the debugged application immediately upon startup of
226 jdb. This option removes the need for using the run command. The
227 debuged application is launched and then stopped just before the
228 initial application class is loaded. At that point you can set
229 any necessary breakpoints and use the cont to continue execution.
230 -listconnectors
232 List the connectors available in this VM
233 -connect <connector-name>:<name1>=<value1>,...
235 Connects to target VM using named connector with listed argument
236 values.
237 -dbgtrace [flags]
239 Prints info for debugging jdb.
240 -tclient
242 Runs the application in the Java HotSpot(tm) VM (Client).
243 -tserver
245 Runs the application in the Java HotSpot(tm) VM (Server).
246 -Joption
248 Pass option to the Java virtual machine used to run jdb. (Options
249 for the application Java virtual machine are passed to the run
250 command.) For example, -J-Xms48m sets the startup memory to 48
251 megabytes.
252 Other options are supported for alternate mechanisms for connecting the
255 debugger and the VM it is to debug. The Java Platform Debugger Archi‐
256 tecture has additional documentation @
257 http://docs.oracle.com/javase/7/docs/technotes/guides/jpda/conninv.html
258 on these connection alternatives.
259 Options Forwarded to Debuggee Process
261 -v -verbose[:class|gc|jni]
262 Turns on verbose mode.
263 -D<name>=<value>
265 Sets a system property.
266 -classpath <directories separated by ":">
268 Lists directories in which to look for classes.
269 -X<option>
271 Non-standard target VM option
272
275 javac(1), java(1), javah(1), javap(1), javadoc(1).
276 16 Mar 2012 jdb(1)