Eclipse Java Debug Perspective Guide

Introducing the Eclipse Java Debug Perspective
A Reference and Tutorial
Overview
Debugging is the process of locating the source of programming errors (often called bugs) and
correcting them. Debuggers are software tools that programmers use to help in this process. Primarily,
we use debuggers to control and monitor the execution of our programs. Specifically, we can use a
debugger to run a program selectively, stopping it at interesting locations and examining its state (the
values that are stored in its variables, which state-change operators modify as a program runs). In this
way we can better understand how a program works —or more importantly, help pinpoint exactly
where a program fails to work correctly as the first step towards determining what changes we must
make to fix it. Thus the process of debugging involves both locating the source of programming errors
and correcting them.
We can instruct a debugger to continually display the current values stored in all (or selected)
program variables; this process is called observing variables. Then, we can execute our program one
line at a time (this process is called single stepping through a program). After each step, we can
observe the new values stored in the variables. We can also have the debugger automatically run the
program but set an unconditional breakpoint on a line of code, which instructs the debugger to stop
the program when it is about to execute that line; in addition, we can set a conditional breakpoint to
stop a program when it is about to execute a line, but only when some specified condition (a boolean
expression) evaluates to true when that line is about to be executed.
This document explains and demonstrates how to use the Eclipse Debug perspective. While reading this
document, look for the  symbol, which instructs you to practice the debugger commands that were just
discussed. Debuggers are sophisticated tools with many subtle features. Although this document is only a
brief introduction, designed for novices, it covers the rudiments of the most important and useful debugger
commands. Finally, during the semester we will use the illustrative power of the Debug perspective to help
us learn and understand new Java language features.
Learn in haste;
debug in leisure
A debugger is an important tool that can save us lots of time. I estimate that for every hour that you
spend learning about the Debug perspective or practicing using it, you will save at least 3 hours later in
the semester, when you are locating and correcting execution errors in your programs. But debuggers
are not a substitute for thinking. They help automate hand simulations, but they do not automate the
inductive and deductive processes necessary to locate and fix bugs in a program. So do not be misled;
when asked, “What is the most important tool for debugging?”; your answer should be “my brain”.
Switching to the
Eclipse Debug
Perspective
Before we can debug a program, we must open its project and compile the program without any syntax
errors or warnings. Then we are ready to run and debug it.
 To follow along with this handout, first copy onto the desktop the collatzfordebugging project
(do it now), which accessible off the Sample Programs page; in the Java perspective, load it into
Eclipse as an existing project. Actually, this program is correct: it contains no bugs. But, we will use
this program to study the features of the Debug perspective. Before proceeding, please read the
comments that describe this program; then, compile it and run it a few times, experimenting with it and
observing its output.
We are now ready to switch to the Debug perspective. The button for this perspective, labeled
Debug (preceded by a bug icon: see the left margin) should appear on the top-right tab, next to the
button labeled Java. If the Debug button is there, click it; if it is not there, you can put it there by
clicking the Open Perspective button on the left of the tab and selecting the Debug perspective (or by
selecting Window | Open Perspective | Debug on the pull-down menu. The Java and Debug buttons can
be reduced to only their icons by clicking on any of the tab buttons and unchecking the Text option.
 In the collatzfordebugging project, click the Debug perspective button. You should see the
Eclipse window change to the Debug perspective.
1
Debug Toolbar
(gray: not debugging yet)
Add Perspective
(button)
Java Perspective
(button)
Debug Perspective
(button; active)
Debug View
(shows previous run
from Java view)
When the debugger is
active, this tab will show
the program’s variables
Outline View
(of Application.java)
We’ll examine the
Breakpoints tab a bit later
Edtor View
(from Java view)
Console View
(shows previous run
from Java view)
This picture illustrates (and labels) the standard size and layout of these windows in the Debug perspective,
which was designed to make the most important debugging windows easily accessible. We can change the size
and layout of any windows in this view, including removing any of their tabs or even the windows themselves.
If we click the debug button (
) on the main Eclipse tool bar, Eclipse will run the entire program under
control of the Debug perspective. If we do this now, though, Eclipse will run the program just as it did in the
Java perspective. To actually start debugging this program, we first must set a breakpoint (discussed in more
detail later) by double clicking in the margin to the left of the line public static void main(String[] args) which
appears in the editor window in the Application.java tab.
 Double-click on this line to set a breakpoint. A blue circle (
2
) should appear there, as shown below.
Now click the debug button (
) and Eclipse starts running the program under control of the Debug
perspective. you should see the following changes to the screen.
Notice that the tool bar holding the Debug tab now appears in color (not gray).
The Debug Tab
The window with the Debug tab contains a stack under Thread[main], listing all the methods called in a
program. They go from the oldest (main, at the bottom) to the youngest, the one currently executing (at the
top). Generally, each method in the stack lists the line number (line XX) on which it called the method listed
above it in the stack. The top method is special: its line number shows on which line the program is currently
executing. In the picture above, main is the only active method, and it is currently executing on line 55.
The Debug tab allows us to monitor method calls. We can click any method named in this stack: the name
is then highlighted, a tab in the editor view displays that method’s code, and the Variables tab (described
below) displays the values of that method’s parameters and local variables. Later in the semester, when we
study how to write Java methods, we will learn more about interpreting the information in the Debug tab
(and more about the editor window and Variables tab, too).
Whenever we start to debug a program with a breakpoint on the main method, we will see one
highlighted entry in the Debug tab: Application.main(String[]) line XX. In this picture, it refers to the
main method in the Application class/tab in the editor view, which is executing on line 55. Some
main method is always the starting point for a Java program.
Below is a picture of the tool bar holding the Debug tab, labeling the meanings of its import buttons.
3
Resume
Suspend Terminate
Step Into Step Over Step Return (active in non-main)
Remove All Terminated Launches (active when any launches terminated)
4
The Editor Tab
The Editor window shows the line of Java code that is about to be executed, both by showing a rightpointing arrow in that line’s left margin and by highlighting that line in green (in one of the class/file
tabs in the editor window). As we execute the statements in a program (see single stepping below), the
arrow will move from line to line along with the highlighting. If we hover over a declared/initialized
variable, its name and value will appear in a yellow window below the hover.
When we set a breakpoint on a method, the Debug perspective stops on the first statement inside the
method: in this case the declaration of cycleCount. Note that when the Debug perspective stops on a
line, it has not yet executed that line: it is about to execute it.
By selecting any method in the Debug tab, we can easily see where in that method our program is
currently executing (either in the same class/file tab, or in another one the Debug perspective creates).
As we see below, we can also see that method’s variables in the Variables tab.
The Variables Tab
The Variables tab lists the names and values of all the parameters and local variables that are currently
declared and initialized (they will not show until they are both declared and initialized) by the
highlighted method in the Debug tab. By selecting any method named in the Debug tab, we can see its
code (in an editor view) and all of its declared and initialized variables (in the Variable tab).
A value that is not primitive (int, double, boolean, char) is an object. Objects appear in the
Variables tab prefaced by a disclosure box containing either a + or - sign. If we click a + box, it
changes to a - box and disclosed the fields of that object; if we click - box, it changes to a + box and,
elides its fields, so that they are not displayed. Later in the semester, when we study Java classes, we
will learn more about using these +/- boxes.
If there are too many entries in the Debug or Variables tab to display all at once, we can scroll
through them. We can also simultaneously increase/decrease the sizes of the Debug and Variables tabs
by pulling downward/upward on the horizontal line that separates these panes from the Editor tab.
Doing so increases/decreases the size of these tabs (and the Editor tab).
When a program starts, the Variable tab will always display the parameter named args, declared by
the main method. Soon we will see how to step over the statements that declare the local variables
cycleCount, originalNumber and testNumber, which will sequentially appear in the Variable tab
along with their initial values.
Finally, as an option, we can click the Show Type Names button (
) on the Variables tab to
toggle whether or not the type names of the variables appear preceding them in the window.
Maximizing Tabs
Remember, to maximize any of the tabs, just double-click it (and double click it again to midimize it). For more
extensive manipulate, use the buttons on the right of the tool bar holding the tab. Try this now, with each of these
three views (Debug tab, editor, and Variable tab).
Single Stepping
Single stepping allows us to execute our program very slowly: one line at a time. When we combine
single stepping in the editor view with observing the values of variables in the Variables tab, we can
carefully trace the execution of our program easily. Such tracing allows us to understand exactly how
the computer is executing our program: what code it is executing and how that code is changing the
states of its variables. These actions help us detect and correct any errors —differences between what
the computer is doing and what we wanted the computer to do.
Most debuggers support at least three kinds of single stepping: Step Over, Step Into, and Step
Return. The buttons for these three stepping operations, as well as a few others, appear on the tool bar
holding the Debug tab.
The Debug Tool Bar
The Debug tab has a special toolbar with about ten buttons. We click them to control how Java runs the
program that we are debugging. Briefly, the most important are
 Resume
 Execute the program until it ends, or until a breakpoint (see below), is reached.
 Suspend
 Stop an executing program; it is almost never used (except to stop an infinite loop).
 Terminate
 Terminate a debugging session; we can always start a new debugging session by rerunning the
program: that is, by clicking the debug button.
 Step Into
 Stop at the first Java statement inside a call to the method in the line about to be executed; we
will examine this button later in the semester, after we learn how to write our own methods.
5
 Step Over
 Execute one Java statement; we will explain this button in detail below.
 Step Return
 Execute all Java statements until the end of a method; also covered later in the semester.
Finally, the Remove All Terminated Launches button (
) cleans up the Debug tab by clearing it.
The Step Into and Step Out buttons are useful only when we are debugging programs that call
methods that we have written (not applicable in collatzfordebugging), so we will defer discussion of
these buttons until later in the semester, when we learn how to write our own Java methods.
If any of these buttons appears gray, it means that the button is not currently usable: clicking it has no
effect. For example, if no program is running, the Terminate button is gray; clicking it has no effect.
Stepping Over
The Step Over button executes one line in a Java program: the highlighted line. If that line contains a
method call, it executes the complete method call without showing us any of the method’s details (any
of the code/variables inside the method). We say that Step Over treats all methods as black boxes.
When we use Step Over in a program
 The blue arrow/green highlighting indicates the line that Java is about to execute; clicking Step
Over executes that line, at which point and the blue arrow/green highlighting moves to the next line
that Java will execute.
 If any variables’ values change during the execution of a step (are not just are stored into, but a different
value is stored into them), the variables and their new values turn red in the Variables tab. If any
variables’s value do not change during the execution of a step, they appear in black.
 In the collatz program, the blue arrow/green highlighting refers to the line containing the
declaration, and initialization to 1, of the cycleCount variable. Click the Step Over button once;
notice that the variable cycleCount appears in the Variables tab and its value 1 appear in black (not in
read because nothing changed; 1 is its initial value). The blue arrow/green highlighting now refers to
the line prompting the user to enter the initial value of the originalNumber variable, which it
declares.
Important Point: The blue arrow points/green highlighting refer to the line that is about to be
executed; when we click the Step Over button, Java executes the line being referred to. It is a common
misconception that the blue arrow/green highlighting refers to the line that has just been executed. The
difference is sometimes critical.
Stepping over Input in
The Console Window
Whenever we Step Over a line that requires input from the user, the Console tab becomes critical;
typically, it contains a message telling the user what information to enter, and it waits for the user to
enter this data. You will notice that the Resume and Step buttons become gray (indicating we must do
something else —enter the requested information— before returning to our stepping). We must now
make the Console active by clicking it. Although the cursor appears at the front of the prompt, if we
type a value it appears in the Console tab after the prompt.
 In the collatz program, click the Step Over button once more, to step over the declaration of
originalNumber, which prompts the user to enter an initial value. Active the Console tab: observe
that it contains a request to Enter a positive integer: Type the value 5 and then press the Enter key.
Notice that orignalNumber now appears in the Variable tab, which shows that stores the value 5.
Click the Step Over button once more, to step over the declaration and initialization of testNumber,
which stores the value from orignalNumber.
Terminating a Debugging
Session (and possibly
restarting one)
To terminate a debugging session (possibly to begin stepping through the program from the beginning again:
it is easy to step too far, which requires going back to the beginning) click the Terminate button on the
Debug tool bar. In this case the debugger terminates the program immediately: the blue arrow/green
highlighting disappear from the editor view. In the Debug tab, the main method (and any other methods that
have been called) are removed from the call stack, and replaced with a terminated message.
Another way to terminate a program is to click the Terminate button on the tool bar that holds the
Console tab. To start debugging over again, click Terminate and then the debug button again.
 In the collatz program, click the Terminate button. Then, start a new debugging session by
clicking the debug button. Step completely through the program. Again, enter the value 5 when
prompted. Observe the entire execution of the program (with this input, it takes six cycles). Observe
which lines are executed in the editor view, which variables are changed in the Variables tab as each
6
line in the program executes
(notice that state changes
appear in red, and then go
back to black when different
states change), and what
information
is
displayed/entered in the
Console window.
7
This is a slow but simple way to execute a program
Breakpoints
Step Over allows us to observe the statements executed in our methods/control structures. At each step, the
Variables tab allows us to observe the changes made to values stored in our variables. Step Over allows
us a fine grain when observing our program. By setting a breakpoint on a line, we can run the program
—at high speed— until that line is about to be executed (instead of tediously single stepping to that
line). Often we need to ignore earlier lines in our program; stop somewhere in the middle of it; and
then Step Over that line and subsequent lines carefully, observing changes to our variables. This
requirement is easily met by setting breakpoints, which come in two varieties: unconditional and
conditional. Let us look at each kind of breakpoint separately. Unconditional breakpoints are simpler.
Setting Unconditional
Breakpoints
When we set an unconditional breakpoint on a line, the Debug perspective will stop the program
whenever it is about to execute that line. This might happen when we first click the debug button, or
after while debugging the program, after we click the Resume button.
The easiest way to set an unconditional breakpoint on a line is to double-click in the margin to the
left of that line in the editor view (as we did above for the declaration of the main method). If a
breakpoint is not settable on that line, a breakpoint is set on the next line after it that can hold a
breakpoint. When a line is breakpointed its left margin changes to a blue circle (the icon is a bit
different depending on whether the line declares a method or is a statement, and whether the
breakpoint is unconditional or conditional); also, an entry for each breakpointed line appears in the
Breakpoints tab: the entry shows whether the breakpoint is enabled (the box is checked if is is) the
name of the class (its line number in the method) followed by the name of the method: in our example
above, it displays: Application [entry] - main(String[]) here it displays entry instead of a line
number, because we set the breakpoint on the method, and the Debug perspective stops on entry to the
method. If instead we set the breakpoint directly on the declaration of cycleCount, the breakpoint
would appear as: Application [line: 55] - main(String[])
We can set breakpoints on many different lines in a program. When we start debugging the program, by
clicking the debug button, Java runs the program, executing lines until it is about to execute any breakpointed
line. The Debug perspective shows us which breakpointed line was reached first by the blue arrow/green
highlighting. When Java stops before executing that line, all changed variables in the Variables tab will
appear in red.
 In the program in the collatzfordebugging project (it should be stopped on the first line not, terminate
it and click the debug button), click the column on the left of the editor view, to the left of the line that begins
testNumber = testNumber/2; this line is executed only when testNumber is even (its execution is
controlled by the if statement). Observe the blue circle to the left on this line and the entry in the Breakpoints
window. Now Step Over the declaration/initialization of cycleCount; then, click the Resume button to
execute this program (enter the value 5 when prompted). The program stops on the breakpointed line (with
the blue arrow/green highlighting referring to this line), the first time that it is about to be executed. Observe
the values for the variables cycleCount (in red) and testNumber (in black) in the Variable tab when the
program stops before executing this line. See the top of the next page for a picture of the state of Eclipse.
Notice the blue arrow and blue circle overlap
 Click the Resume button again; again, observe where the program stops and the values listed for
these variables again (and in what colors) and the contents of the Console tab. Continue clicking the
Resume button and making observations until the program terminates. After the program terminates,
click the debug button and again user Resume execute the program. This time enter a value of 17 to
the prompt and watch the behavior or even and odd values.
Removing (or Unsetting)
Breakpoints
If we no longer want the debugger to stop the program on a breakpointed line, we can easily remove
its breakpoint. The easiest way to remove a breakpoint from a line is to double-click the blue circle
indicating a breakpoint in the left margin of a line. The blue circle will disappear. The entry for that
breakpoint will also disappear from the Breakpoints tab. We can also remove a breakpoint by rightclicking the breakpoint in the Breakpoints tab and selecting delete.
If we do not explicitly remove a breakpoint, and then terminate the program and run it again, that
breakpoint (and any others that we set and did not remove) will still be there. With this feature, we can
easily execute the program repeatedly, keeping the same breakpoints. In fact, if we terminate Eclipse,
it will remember what we were debugging and what breakpoints were set when we restart it.
8
 Rerun the program in
the collatzfordebugging
project a few times in the
Debug
perspective.
Terminate Eclipse, restart it,
and run the program again.
Notice that the breakpoint
that you set previously is
still there; finally, remove
that breakpoint.
Setting Conditional
Breakpoints
Sometimes we need to stop at line in a program, but not every time that the line is about to be
executed: instead, we want to be more restrictive, and to stop there only when some special condition
holds. Conditional breakpoints are an advanced feature that allows us this extra control by allowing us
to attach a boolean condition to any existing breakpoint. When the program is about to execute a line
with a conditional breakpoint, Java first evaluates the condition: it stops the program before executing
that line only when the condition evaluates to true. This simple mechanism increases the utility of
breakpoints tremendously. Now, let’s see how to set a conditional breakpoint and specify its condition.
 Set an unconditional breakpoint; the breakpointed line will appear in the Breakpoints window.
 Right-Click its blue circle (and select Breakpoint Properties…) or right-click the breakpoint in the
Breakpoints window (and select Properties); a box like the following will appear.
9
10
 Check the Enable Condition box; the text area beneath it becomes white.
 In the text area enter a valid condition (any legal Java boolean expression). Typically, the
expression will refer to variables that appear in the Variables tab for that method.
 Click the OK button.
We can reexamine/change the condition for any breakpoint by retrieving its properties window and
editing the text area that contains its condition.
 In the program in the collatzfordebugging project (it should be stopped on the first line), set an
unconditional breakpoint on the line that begins if (testNumber == 1). Then make it a conditional
breakpoint by typing the boolean expression testNumber < 1000. Now click the debug button to run this
program (Enter the value 7777 when prompted): it will stop on the breakpointed line the first time that the
condition is true. Notice the variables in the Variables tab when the program stops: testNumber is 923
(<1000) and cycleCount is 17 (both appear in Red). Scroll back in the Console window to see what output
the program produced during these 17 cycles; note that all prior values for testNumber were  1000. Click
the debug button again and observe what happens. Terminate the program and debug it again, with the same
conditional breakpoint; this time enter a different value when prompted (again, a value  1000). Observe a
similar pattern.
Notice that when programs run with conditional breakpoints, their execution speed diminishes
(sometimes dramatically); this is the price that we must pay for using such a powerful tool.
Finally, if we enter an illegal boolean expression into the white text area for a condition (typically
illegal because of bad operator syntax or bad variables names), the Debug perspective does not notice
the error until the condition is checked (the first time its line is reached). At this time, the breakpoint is
activated (just as if the condition evaluated to true) and we see the following message
We can either Cancel, or Edit Condition and re-edit the condition in the properties box for this
breakpoint. In either case, we are stopped at this breakpoint and can click any of the buttons on the
tool bar holding the Debug tab.
Disabling Breakpoints
(and re-enabling them)
Sometimes it is useful to temporarily disable a conditional breakpoint, rather than completely remove
it. A disabled breakpoint has no effect, but it can easily be re-enabled to restore its effect. A removed
breakpoint has to be set all over again (a removed conditional breakpoint requires further clicking and
typing to recreate it). To disable a breakpoint, either
 Right-Click its blue circle (to the left of the breakpointed line); the circle will change to white and
the check-box in the Breakpoints tab will be unchecked. Caution: if you double click the blue circle
it will remove the breakpoint
 Click on the checked box in the Breakpoints tab; the effect will be the same in both places.
Finally, to re-enable a disabled breakpoint, either
 Right-Click its white circle (to the left of the breakpointed line); the circle will change to blue and
the check-box in the Breakpoints tab will be checked. Caution: if you double click the white circle it
will remove the breakpoint
 Click on the unchecked box in the Breakpoints tab; the effect will be the same in both places.
If the condition on a re-enabled breakpoint is gray, not black, double click it to restore it.
 In the program in the collatzfordebugging project (it should be stopped on the first line), disable the
conditional breakpoint that you just set. Then, click the Resume button to run this program: it will not
stop on a line with a disabled breakpoint. Then re-enable the breakpoint and restart the program,
entering some value  1000. Now the program stops on the line with the re-enabled breakpoint.
Finally, we can also disable a condition on the properties window of a breakpoint, converting it from
a conditional breakpoint to an unconditional breakpoint, by unchecking the Enable Condition box. The
condition remains in the text area, though, so by rechecking this box we can restore it to the its
original state (as a conditional breakpoint with the original condition).
11
Observing Expressions
It is possible to observe the values of arbitary expressions, not just variables. For example, we can
easily observe the maximum of originalNumber and testNumber by first right-clicking on
testNumber in the Variables tab and then selecting Watch. The Expressions tab below on the left will
be added to the view holding the Variables and Breakpoints tabs, watching testNumber. Its
expression is just the variable itself. To enter the expression we want, right-click the entry for
testNumber and select Edit Watch Expression.
Then we type in any legal Java expression. The Expressions tab above on the right shows the
expression and its value. We can perform other operations (see above left) by right-clicking a watch in
the Expressions tab. If a watched expression contains a syntax error (or an unknown variable), a
disclosure box will appear in front of it, and will look something like the following (here I forgot to
put a comma between the arguments to the Math.max method) when disclosed.
Restoring Tabs
To restore any views (like the Variables or Breakpoints tabs) if you remove them, click the Window
pull-down menu and then select the view you want to see.
Finally, when we terminate the debugger, Eclipse saves the contents and locations of all these
windows. So, when we begin another debugging session (possibly after closing the entire project and
reopening it at a later date), the desktop looks identical to when we last terminated a debugging
session.
 Problems
(with solutions on the next
page; don’t peek until you
have attempted to solve
these problem)
Solve each of the following problems by setting breakpoints on various lines in the collatzfordebugging
program; most of the breakpoints also require conditions. Do not change the program or single step to find
the answers (use breakpoints to find them much faster). First determine where to set the breakpoint, then
determine under what condition to stop at that breakpoint (this reduces one hard task to two simpler ones).
 For an input of 5184 what cycle is the first one where testNumber is odd?
 For an input of 18743 on what cycle does testNumber first drop below 1000?
 For an input of 77777 does testNumber ever equal 1336? If so, on which cycle?
 For an input of 77777 what values does testNumber have on cycles 20, 40, 60, etc.?
There are simple and elegant ways to solve all these problems.
Current End of Handout
…but more coming
For now, you are done with this handout. Please ensure that you have an operational understanding of the
various windows and panes that are part of the debugger, how to single step through a program, and how to
set, remove, and disable unconditional and conditional breakpoints. These operations are the primary ones
that you’ll need for the first few weeks of class. When I complete this handout, I’ll announce it in class.
A Peek at Things Ahead
Viewing Complicated Data: Complicated data (such as objects constructed from classes, and arrays)
often show up in the Variables pane with a +/- boxes. Click the box to toggle between
disclosing)/eliding(not-seeing) the members of the data. There are also special observer windows for
displaying the members of complex data.
Changing Values: We can use the debugger to change the values stored in variables. This operation
is a bit delicate, and there are very very very (yes, not a typo) few times when it is useful. We
accomplish this by right-clicking a variable in the Variables tab and selecting Change Value (and then
entering the new value in the text box).
12
Stopping an infinite loop: If a loop is infinite (no progress is being made towards loop termination
inside the body of the loop), we can stop it in the debugger by clicking the Suspend button. Typically,
the Debug tab will have lots of names in it, and the programmer must click the Step Return button
multiple times to return to the main method. Then the programmer can use Step Over to locate the
infinite loop, and continue to use stepping to diagnose why the loop is not making progress toward
termination. Often we observe an infinite loop by the Console window printing nothing (it almost
looks like the program has stopped) or printing the same thing repeatedly, over and over again. After
stopping, scroll up and select main in the Debug tab.
Step Into/Step Return: When we begin writing our own methods (instead of just calling functions
that are already written in the class library) we will discuss Stepping Into and Stepping Out Of, which
treats methods as white boxes: when we Step Into a line containing a method call, the debugger goes
into that method so that we can see its parameters, and how it works by executing its lines one at a
time. We can single step in a function, Step into any method that it calls, or Step Out that method to
the line following the one where the function was called.
Controlling the display of final and static variables: Constants (specified with final) and static
variables can be electively displayed in the Variable tab. Click the down-pointing black triangle at the
right of the tool bar that holds the Variable tab and check/uncheck the appropriate option
Debugging Strategies: We will also discuss general strategies for quickly locating errors in
programs. Often once the location of a bug is detected, we can easily determine how to fix it.
 Solutions
Here are the solutions for the problems above. When answering questions about the current
cycleCount and testNumber, it is convenient to set a breakpoint on the if (testNumber == 1) line,
which occurs directly after their current values are displayed to the console window.
 For an input of 5184 what cycle is the first one where testNumber is odd?
 Answer: on cycle 7 (testNumber is 81)
1) Set a breakpoint at the line starting if (testNumber == 1) with the condition
testNumber %2 == 1
2) Set an unconditional breakpoint at the line testNumber = 3*testNumber + 1; this stops
on the first odd number, but AFTER cycleCount has been incremented (so it will show
as 8, not 7).
 For an input of 18743 on what cycle does testNumber first drop below 1000?
 Answer: on cycle 81 (testNumber is 572)
Set a breakpoint at the line starting if (testNumber == 1) with the condition
testNumber < 1000
 For an input of 77777 does testNumber ever equal 1336? If so, on which cycle?
 Answer: on cycle 100 (testNumber is 1336)
Set a breakpoint at the line starting if (testNumber == 1) with the condition
testNumber == 1336
 For an input of 77777 what values does testNumber have on cycles 20, 40, 60, etc.?
 Answer: on cycle 20, testNumber is 6922; on cycle 40, testNumber is 1853; on cycle 60,
testNumber is 496; on cycle 80, testNumber is 137; on cycle 100, testNumber is 1336;
Set a breakpoint at the line starting if (testNumber == 1) with the condition cycleCount % 20
== 0
13
Problem Set
Use the Debug perspective to Observe the program in the crapsstatisticsfordebugging project.
Before proceeding, please read all the comments at the top of that program, which describe it; then,
compile and run it a few times. Below are a variety of questions about this program, all of which can
be answered by using various combinations of the standard debugger commands: i.e., observing the
Variables tab while stepping/running the program under the control of unconditional and conditional
breakpoints (similarly to the problems/solutions in the handout above).
For example, question 1 (below) can be solved by observing the variable game (which keeps track
of the game number: first, second, third, etc.) and setting a breakpoint at the unique line that is
executed when a loss occurs on a first throw of the dice.
Determine both the answers to the questions and a general explanation of the methods (the debugger
commands: where and with what conditions) that you used to answer these questions.
To start the assignment, you will have to download and modify the crapsstatisticsfordebugging
project
 Download the crapsstatisticsfordebugging zip file onto your desktop and then unzip it
 Open Eclipse and use the Java perspective to start the project.
 Open an Editor view of the Application.java file in it.
Add another import command directly below the first one:
import java.util.Random;
Add a line in this file, directly before the definition of the throwsDice method:
private static Random randGen = new Random(0);
Alter the for loop body in the throwsDice method to read:
sum += Math.round(randGen.nextDouble()*6. + .5);
 By making these changes the program will generate a standard sequence of random numbers, so
its results will be identical each time that you run the program. This is a very useful feature
when the program you are debugging, or trying to gather information about, uses a random
number generator.
 Run the program after these change. Then switch to the Debug perspective. Ensure that the program
runs correctly before setting any breakpoints.
 Make no other changes to the program: this assignment does not require programming.
Single step through the program for a few games to better understand the execution of this program
and its control structures. Specifically, watch how the information stored in the variable roll controls
what statements the program executes; also observe where/how the program changes game,
winCount and loseCount.
Determine how to use debugger commands to help you answer the following questions. Each
question requires its own/different debugging session. Make no changes to the program itself.
1. What number game is the first to be lost on one throw (e.g., 2, 3, or 12)?
2. What are all the dice throws in the second game (list them in the order thrown)?
3.What number game is the first to be won on a throw of 7? 11?
4.What number game is the first to be lost on a throw of 2? 3? 12?
5.What number game is the first to be won by making a point of 5? 10?
6. What are all the dice throws in game 73?
7. In what game number does the 712th win occur? (this program can run for a few minutes)
Hints
Enter 2000 when prompted Enter # of games to play: all answers correspond to earlier games than
this one. This bound is important because a program with breakpoints (especially conditional
breakpoints) will run slowly compared to the same program without breakpoints. So, once you set
your breakpoints, it may take some time for the debugger to stop the program on the appropriate line
(a few minutes, at most): if you set incorrect breakpoints, you do not want the program to execute for
more than a few minutes before you find out.
14
">