1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for Linux/x86 (vers 1st February 2002), see www.w3.org">
<title>Breakpoints</title>
</head>
<body>
<h2>JSwat Breakpoints</h2>
<h3>How to Set Breakpoints</h3>
<p>JSwat supports setting breakpoints inside classes, including
inner classes. Breakpoints can be set in at least two ways using
JSwat. First there is the command '<code>stop</code>' which
can be used to set a breakpoint at a method in a class or at a code
line in the class. Second, there is the "Set Breakpoint"
item in the "Debug" menu, and finally there is a button
in the toolbar. This presents a dialog which allows you to set a
breakpoint at a code line in a class.</p>
<p>For using the '<code>stop</code>' command, type
'<code>help stop</code>' to learn the syntax for the
command. It is generally of the form "<code>stop
<class>:<line></code>" where <class> is the
name of a class and <line> is the code line at which to set
the breakpoint. To set a breakpoint inside an inner class, use the
dollar sign ($) to separate the names of the outer and inner
classes. Some examples are:</p>
<pre>
> stop MyClass:213
> stop mypackage.MyClass.myMethod(java.lang.String, int)
> stop *.ClassName$Inner:41
</pre>
<p>The second example demonstrates setting a breakpoint at a
method, by giving the method name and argument types. You do not
give the argument names, just the fully-qualified argument
types.</p>
<h3>What Breakpoints Do I Have Set?</h3>
<p>Any breakpoints that have been set and resolved are assigned
numbers. The numbers assigned to a breakpoint remain in effect for
the life of the breakpoint. To see the breakpoints and their
numbers, use the '<code>stop</code>' command with no
arguments. To see the breakpoints in a dialog, select the
"Breakpoints..." menu item. There is also the panel
labeled "Breakpoints".</p>
<p>Breakpoints are also visually displayed in the source code
viewer. The breakpoints are displayed by colorizing the area on the
left margin of the source window. Resolved breakpoints are colored
with green and disabled breakpoints are gray. Breakpoints that have
expired are red. Unresolved breakpoints are blue. Breakpoints that
are skipping hits are yellow.</p>
<h3>How to Disable/Enable Breakpoints</h3>
<p>There are at least three ways to disable and enable breakpoints.
The first is through the '<code>disable</code>' and
'<code>enable</code>' commands. These each take the number
of the breakpoint (as described above) to disable or enable.</p>
<p>Another way to disable or enable breakpoints is to use the
"Breakpoints..." menu item. This presents a dialog that
shows all the set breakpoints. Select a breakpoint in the dialog
and click either the "Disable" or "Enable"
button, as desired.</p>
<p>Yet another way to disable and enable breakpoints is by using
the source code viewer. If a source file is displayed which
contains breakpoints, you can right click on the code line with the
breakpoint and a popup menu will appear. This menu has items to
disable, enable, and remove breakpoints.</p>
<h3>How to Clear Breakpoints</h3>
<p>There are at least three ways to clear breakpoints. The first is
through the '<code>clear</code>' command. This takes the
number of the breakpoint (as described above) to remove.</p>
<p>Another way to clear breakpoints is to use the
"Breakpoints" menu item. This presents a dialog that
shows all the set breakpoints. Select a breakpoint and click the
"Remove" button to remove the breakpoint.</p>
<p>Yet another way to clear breakpoints is by using the source code
viewer. If a source file is displayed which contains breakpoints,
you can right click on the code line with the breakpoint and a
popup menu will appear. This menu has items to disable, enable, and
remove breakpoints.</p>
<h3>Grouping Breakpoints</h3>
<p>Breakpoints are automatically added to a breakpoint group called
"Default". Via the breakpoints manager dialog (accessible
via the "Debug" menu) it is possible to create new
breakpoint groups and move breakpoints to that group. Breakpoint
groups can be disabled, causing all of the breakpoints contained
within them to also be disabled. Re-enabling the group will restore
the breakpoints to their original enabled state.</p>
<p>Breakpoint groups can contain other groups, which may contain
yet other groups.</p>
<p>Deleting a breakpoint group will delete all of the breakpoints
and groups contained therein.</p>
<p>The "Default" breakpoint group cannot be deleted and
it will be automatically re-enabled whenever a session is
restarted.</p>
<h3>Skipping and Expiration</h3>
<p>All breakpoints support the notion of skipping and expiration.
Skipping means that a breakpoint will be hit but will immediately
resume execution of the debuggee VM until the breakpoint has been
hit enough times. A skip value of zero means the breakpoint will
not skip at all. Expiration is when a breakpoint has been hit
enough times that it is no longer useful. This is the inverse of
skipping, where the breakpoint will halt execution of the VM until
the breakpoint expires. An expiration value of zero means the
breakpoint will never expire.</p>
<p>If the skip value is larger than the expiration value (assuming
the expiration value is non-zero), the breakpoint will effectively
never halt execution of the debuggee VM.</p>
<h3>Manipulating Multiple Breakpoints</h3>
<p>This is very easy to do. Simply select all of the breakpoints
you want to modify in the breakpoints panel, then select the button
to modify them. You can enable, disable, and remove multiple
breakpoints just be selecting them.</p>
<h3>Breakpoint Conditions</h3>
<p>Breakpoints may have one or more conditions assigned to them,
allowing you to avoid hitting the breakpoint more often than is
necessary. Presently only one type of breakpoint condition is
supported, called a "value" condition. The condition is
satisfied when the named variable (e.g. "obj1.fieldx")
equals a particular value (e.g. "123"). The variable type
must be a primitive (boolean, byte, char, double, float, int, long,
short) or a String.</p>
<h3>Breakpoint Monitors</h3>
<p>Breakpoints may have one or more monitors assigned to them. A
monitor is something that is "performed" whenever the
breakpoint is hit and the breakpoint is not disabled, skipping, or
expired. Presently only one type of monitor is supported, called a
"command" monitor. When this monitor is performed, the
named command is executed, just as if you had entered it yourself.
For instance, you could add a monitor to invoke the
"where" command whenever the assigned breakpoint is hit.
In addition to the built-in commands, any defined alias or macro
can be used.</p>
<h3>Thread Suspend Policy</h3>
<p>Normally when a breakpoint causes execution of the debuggee VM
to stop, all of the debuggee threads are suspended. This behavior
can be modified with the breakpoints properties dialog. The
"Suspend Threads" radio buttons indicate which threads
should be suspended when the breakpoint is hit. "None"
and "All" are obvious, while "Event" may be
unclear. The event thread is the one in which the breakpoint event
occurred.</p>
<h3>Filters</h3>
<p>Location-based breakpoints (line and method) support thread
filters. That is, the breakpoint is only considered hit if it
occurs on a particular thread or threads. The set of threads can be
manipulated using either the breakpoint properties dialog box, or
through the <code>filter</code> command.</p>
<p>Traces and exception catches can have both thread and class
filters. A class filter causes the trace or catch to only operate
when the event occurs within the given class or classes. The set of
class can be manipulated using either the breakpoint properties
dialog box, or through the <code>filter</code> command.</p>
</body>
</html>
|
