When you are using the debugger, your program can be in one of two possible states: running or suspended.
To resume program execution, choose the Resume Program icon on the debugger toolbar. When the debugging session is ended, this icon becomes the Restart Program icon
and restarts the session.
To end the current program run, do one of the following:
Resetting a program releases resources and clears all variable settings. However, resetting a program does not delete any breakpoints or watches that you have set, which makes it easy to resume the debugging session.
To restart the program, click the Restart Program icon on the debugger toolbar.
The execution point marks the next line of source code to be executed by the debugger. When you pause the program's execution in the debugger, the current execution point for the selected thread is highlighted. The execution point always shows the next line of code to be executed, whether you are going to step over, step into, or run your program without stopping.
To find the current execution point,
While debugging, you're free to open, close, and navigate through any file in the editor. Because of this, it's easy to lose track of the next program statement to execute, or the location of the current program scope. To quickly return to the execution point, choose Run|Show Execution Point or click the Show Current Frame icon on the debugger toolbar.
This is a feature of JBuilder Professional and Enterprise.
The default display of the Threads, call stacks, and data view is split into two panes. The left side of the view can expand to show stack frames. The right side displays the content of the item selected on the left, allowing the right side to show anything from a thread group to a variable. For example, if a thread is selected in the left view; the right side of the view will show the stack frames for that thread. Alternatively, if a stack frame is selected in the left view, the right view will show the variables available in that view.
To display the call stacks and data for the current thread only,
To display the current thread's top stack frame, click the Show Current Frame icon on the debugger toolbar.
To choose the thread to step into,
This is a feature of JBuilder Enterprise.
After the debugger has been suspended, and you're ready to resume execution, you can optionally keep a thread suspended. This allows you to watch the behavior of the just the threads you want, without interference from the others.
To resume program execution, choose the Resume Program icon on the debugger toolbar. When the debugging session is resumed, only the threads not kept suspended will be resumed.
To keep a thread suspended,
The ability to detect deadlocked threads is a feature of JBuilder Enterprise.
In this view, each monitor shows the thread that owns it and the threads, if any, that are waiting to get it. When a monitor is in a deadlocked state, more than one thread is trying to get it. However, it cannot be released, because the thread that is holding it is waiting for another monitor to be released. The glyph shows that a monitor is deadlocked.
When you expand each monitor in the view, you'll see all the threads that are waiting for it, as well as the thread that owns it. Note that the glyphs in this view just show whether that thread is the currently active one. Each thread can be expanded to show its current stack, as it can in the Threads, call stacks, and data view.
In the example below, both threads 1 and 2 have waiting threads. Threads 4, 3, and 1 are waiting for thread 2; thread 2 is the owner - "monitor2" is the name of the thread object. Thread 4 is the current stepping thread.
or Step Over
icons on the debugger toolbar.
The smallest increment by which you step through a program is a single line of code. Multiple program statements on one line of text are treated as a single line of code; you cannot individually debug multiple statements contained on a single line of text. The easiest approach is to put each statement on its own line. A single statement that is spread over several lines of text is treated as a single line of code.
As you debug, you can step into some methods and step over others. If you're confident that a method is working properly, you can step over calls to that method, knowing that the method call will not cause an error. If you aren't sure that a method is well-behaved, step into the method and check whether it is working properly. You should step over methods that are in libraries provided by JBuilder or third party vendors. This will considerably speed up your debugging cycle.
If the execution point is located on a call to a method, the Step Into command steps into that method and places the execution point on the method's first statement. Subsequent Step Into commands will execute the method's code one line at a time.
If the execution point is located on the last statement of a method, Step Into causes the debugger to return from the method, placing the execution point on the line of code that follows the call to the method you are returning from.
The term "single-stepping" refers to using Step Into to successively run though the statements in your program code.
There are several ways to issue the Step Into command:
There are several ways to issue the Step Over command:
If Smart Step is on, classes in the Classes with tracing disabled view that are marked as tracing disabled will not be stopped in.
There are two ways to issue the Step Out command:
This is a feature of JBuilder Professional and Enterprise.
The Smart Step toggle allows you to determine if each step is "smart" or not.
When this feature is on, each step operation uses the classes listed in the Classes with tracing disabled view and the Smart Step options selected on the Debug page of the Project Properties dialog box:
When Smart Step is off, classes in the Classes with tracing disabled view, along with Smart Step options, are ignored, so you'll be able to step into all of these classes.
By default, when you start a debugging session, Smart Step is on.
You can have multiple breakpoints in your code. You can customize each breakpoint so it pauses the program execution only when certain conditions occur.
For more information about breakpoints, see "Using breakpoints."
To run to a specific program location,
When you run to the cursor, your program executes without stopping until the execution reaches the location marked by the cursor in the editor. When the execution encounters the code marked by the cursor, the debugger regains control, suspends your program, and places the execution point on that line of code. For more information about the execution point, see "The execution point."
This command speeds up the debugging process, as it allows you to move quickly through code that is error-free.
If your program was compiled with debugging information (the default), this view also shows the arguments passed to a method call. Each method is followed by a listing that details the parameters with which the call was made. In addition, the view shows where each method resides. It lists the line the method call is on, the class name, and the source name.
To view the source code and data state located at a particular method call, click the method.
To locate a method call,
The Classes with tracing disabled dialog box and view are features of JBuilder Professional and Enterprise.
To closely examine part of your program, you can tell the debugger to only trace into the files you want to step through. This way, you can concentrate on a known problem area, rather than manually stepping through every line of code in the entire program. For example, you usually don't want to step through classes that are in the JavaSoft library, because you're not going to troubleshoot them; you usually only want to inspect and troubleshoot your own classes.
To determine what classes are and aren't going to be traced into,
Both the view and the dialog box operate in the same way.
You can enable or disable a class or package in the Classes with tracing disabled view at any time. Simply right-click the class or package and toggle the Step Into Class option. When disabled (the default), the class or package won't be traced into. When enabled, it will be stepped into. Note that the glyph changes for the two states:
You can also remove a class or package from the list by selecting it and and pressing Delete, or by selecting it, right-clicking, and choosing Remove Class/Package. To remove all classes and packages, right-click in an empty area of the view and choose Remove All.
To add a class or a package to the list, right-click in an empty area of the view and choose Add Class Or Package. The Disable Tracing dialog appears, where you enter the name of the class or package to disable tracing for.
Changes take place immediately. You do not need to restart the debugging session.
Classes in the Classes with tracing disabled view, with their enabled/disabled state, are saved in the project file.
Once you've selected the classes you don't want to trace into, use the Smart Step icon on the debugger toolbar to control the tracing. When this feature is on, each step operation uses the classes listed in the Classes with tracing disabled view and the Smart Step options selected on the Debug page of the Project Properties dialog box:
When Smart Step is off, classes in the Classes with tracing disabled view, along with the Smart Step options, are ignored, so you'll be able to step into all of these classes.
Stub source files
If stub source is generated for files for which you have source available, check the source path. The debugger looks in your source path for source files. (The source path is described in the topic called Source Path in the chapter "Creating and managing projects.") The .java file being debugged has to exist in a branch that is the same as its package name.
For example, if your source path contains one item:
c:\MyProjects\Test\src
and your .java file is in a package called mypackage,
the debugger expects the .java file to exist in the directory:
c:\MyProjects\Test\src\mypackage
The package name is appended to the source item name. If you have multiple source items, the debugger will try to locate all of them using the scheme outlined above. If the debugger can't locate the source file, it generates stub source.
A stub source file is displayed in the content pane. It contains a header and method stubs.
A warning dialog box, the Stopped In Class With Tracing Disabled dialog box, will be displayed if:
In this situation, stepping after the breakpoint is hit will cause the debugger to go out of that class. To stay in that class, turn Smart Step off, then use the stepping icons.