Debugging Applications using Pramati Studio Debugger

Studio provides a smart debugger that enables to find and fix bugs across all tiers of an enterprise application. It can be configured to debug the business logic in an EJB. Use the debugger to:

Transparently step into EJB methods from JSPs

View trace for a thread

Debug JSPs while executing the servlets for an application deployed on the built- in Pramati Server

View source-specific threads for clarity of diagnosis

Watch variables as the code executes

Key terms

Remote debugging

Remote debugging is done when an application runs on one computer and debugging is done from another. It is useful when an application encounters a problem on a networked computer and cannot be duplicated on other computer. The computer used to debug a remote application is a Client computer and where the application is deployed is called a Remote computer.

Stack Trace

The order in which a VM maintains stack frames is stack trace. The control flow is organized bottom up. Studying the stack enables to see how the control reached a point.

VM maintains the local variables on the stack separately for each namespace. This is called the Stack Frame. When the control flows from one namespace to another, variables in the new namespace are maintained separately on a different Stack Frame.

Reading a Stack Trace

The stack trace shows all frames including those for which source is not available. It displays the class and local variables at that location. To open the reference file, click the method under Thread Viewer tab.

Editor

The editor contains the pop-up menus for toggling break points set in Java or JSP code. The editor highlights the line where the control is paused.

Console

Thread Viewer

It lists the user threads that are suspended, and also shows the thread hierarchy.

Watches

Adds a watch to the selected text and debugger pauses when it encounters a watch point.

Stack Frame Viewer

Debugger toolbar

Table 1:
Button	Usage
Restart	Restarts debugging an application
Close	Closes the debug tab
Resume	Continues a paused debugging operation
Stop	Stops the debugging operation
Disconnect	Disconnects the Debugger
View Break Points	Displays all the Break Points panel
Step in	Goes to the next statement to be executed
Step over	Continues debugging without stepping in
Step out	Pauses where the selected statement was invoked
Run to cursor	Debugs from the break point to the cursor position
Show execution point	Highlights the statement being executed
Evaluate Expressions	Evaluates any variable in the stack frame

Starting the Debugger

Open a sample desk such as BankDesk located in <install_dir>/samples/ejb11/BankDesk/BankDesk.dsk.

To debug, select Debug > Debug from the main menu or click debug icon in the tool bar and select Edit Entries. The Run/Debug Settings dialog appears.

Local setting

Use this tab when application to be debugged is deployed on one of the configured servers inside Studio

Table 2:
Field	Description
Name	A name to identify the application
Main Class	The main class in a Java file to be debugged
VM Options	Specify the JVM for the application. This field is optional
Arguments	Identifier for the argument to be used at the command prompt
Working Dir	Location to store the debug information
Module	Application module to be debugged

Remote settings

Use this tab when the application to be debugged is deployed on a remote server. Enter the Name to identify the application and enter the following information:

Socket Transport: For application deployed locally or remotely

Host: IP Address of server on which the application has been deployed

Port: Port number of server on which the application has been deployed

Shared Memory Transport: For application and Studio running on different VMs but sharing memory

Address: Address of the deployed application

Deploying the application in built-in server in debug mode

To explicitly start Server in debug mode, select Debug > Debug Server from the main menu. Right click on the desk in the explore panel and select Deploy. This deploys the desk using Express Development. If there are missing references or incomplete mappings, the Deploy Tool appears where the required details should be entered.

Launching the JSP

To launch a JSP in a browser, right click on a JSP such as bank.jsp and select Run. The specified browser comes up with the following URL: http://127.0.0.1:8181/bankWeb/bank.jsp where bankWeb is the context root for the application.

Insert breakpoints on an executable line of Java or JSP code before or after starting the Debugger. To insert a breakpoint, place the cursor at the suitable position in the editor and do one of the following:

Select Debug > Add/Remove Break Point

Click in the gutter

Press Shift + F9

When the execution of a thread reaches a breakpoint, it pauses. To inspect the stack for this thread, open the `Stack Frame Viewer' tab in the output panel. Other threads execute asynchronously but are not shown in the dropdown.

To view the Beakpoints panel, select Debug > Add Line/Method/Exception Breakpoint from the menu bar; configure properties.

For details, read the sections on line, exception and method breakpoints, and field watchpoints.

Adding a line breakpoint

Place the cursor at the suitable position in the Editor and click in the gutter. To modify the properties of a line breakpoint, right click on the breakpoint and select Properties. Enter the following details:

Table 3:
Field	Description
Condition	Set a boolean condition. Debugger stops evaluation when the condition is satisfied
Pass Count	Set the number such as 3. Debugger skips the statement thrice then debugs it and proceeds.
Suspend VM	Continues evaluation without pause
Log Event to Console	Select this to know how many breakpoints have been reached. It is equivalent to a SOP statement.
Log Evaluated Expression	Select this option and type the statement to be evaluated in the field. For example, type i*3 in this field. When debugger encounters this statement, the result is displayed in the console tab.

Adding a exception breakpoint

Select Debug > Add Exception Breakpoint from the main menu or right click on a breakpoint in the gutter and select Properties.

In the Exception Breakpoint panel, click Add. The Add Exception Breakpoint panel appears. Select from the options:

Any exception: Select this option to make Debugger pause evaluation for every exception it encounters

Enter exception name: Type the exception name for which Debugger should pause evaluation

Caught: Debugger pauses evaluating when an exception is encountered

Uncaught: Debugger pauses evaluation for an uncaught exception

Adding a method breakpoint

Place the cursor at a method in the Editor and select Debug > Method Breakpoint from the main menu or introduce a breakpoint by clicking in the gutter, right click and select Properties > Method Breakpoint. The options are:

Entry: Pauses debugging when the Debugger encounters a particular method

Exit: Pauses debugging when the Debugger exits a particular method

Adding a field watchpoint

Provide the class name for example, pkg.Test and a field name. Debugger pauses when the concerned field is accessed from anywhere within the application. Details are displayed in the Watches tab in the output panel.

Evaluate expression

Debugger enables you to evaluate any variable in the stack frame. To do this, click evaluate expression button in the Debugger tool bar and follow these steps:

Type the expression in the Expression field.

Right click the expression to set evaluation value.

Enter a new value in the dialog and click OK followed by Evaluate.

To view details, select Thread Viewer tab.

Removing break points

Select Debug > Add/Remove Breakpoint

For a line breakpoint, click on the breakpoint in the gutter or right click on the breakpoint and select Remove

Once breakpoints are set and Debugger starts, the following functions can be performed after reaching the first breakpoint:

Step In

Step Over

Step Out

The debugger pauses at the breakpoint. It is possible to step into a method, step out, or step over a method, and resume the thread that has been suspended. For details, read the following sections.

Stepping into methods

Select Debug > Step In from the main menu or click Step In icon in the Debugger toolbar.

If the next line of code is not a method call, the Debugger executes the code on the next line and pauses there.

If the next line of code is a method call, Debugger stops at the first line of code of the method that has been called, provided you have the source code for it.

If the source code for the method called is not available, Debugger executes the method while step in remains the same as at the point of invocation.

Note: Stepping into Java core classes and Pramati classes is not allowed. This way you step into classes for which the source code has been written.

Stepping over methods

To step over a method, select Debug > Step Over from the main menu or click Step Over in the Debugger toolbar. Irrespective of the next line of code being a method call or not, Debugger executes the line of code, and the control stops at any breakpoint it encounters, or immediately after. This is conditional on the availability of the source for the next line of code to be executed. Debugger does not stop if the next line of code is in another class for which the source is not available.

Stepping out of methods

To step out of a method, select Debug > Step Out from the main menu or click Step Over in the Debugger toolbar. Debugger executes the current method and the control stops at any breakpoint encountered during execution or immediately after and returns the control to the calling method.

This process is conditional if the source code is available. When execution of a logical block of code ends, debugger pauses at the beginning of the block and highlights the point of step in, step over, or step out. For a line of code that is not a break or return statement, the following holds good:

Table 4:
Step In/Step Over at	Highlight Position
Last line in a try block	Beginning of the try block
Last line of method	Declaration of method
Last line of condition	The condition

The above is true of any JPDA compliant debugger. If a line of code has multiple statements implicit or explicit, after a step in debugger still highlights the same line as the debugger tries to step into the method calls it encounters and bounces back as the source is not available. For example, System.err.println("The value of object x is "+x);

Here the overloaded operator actually is a method call to the append() method of class StringBuffer and the call to toString() method of object x is not so obvious.

Remote debugging

Open the desk that contains the files to be debugged.

In Studio, insert breakpoints as required at executable line of code.

In client computer, launch the VM using settings described in the Remote settings section and then deploy the application on the remote VM.

Create a new Remote Setting in the debug settings panel and make sure that the default Socket transport is selected. Also give the host name of the remote machine.

Click on the remote setting to connect to the remote VM. The execution will pause at a breakpoint if it lies in the execution path. To continue debugging the application, use Step In, Step Out and Step Over as explained in the section `Controlling program execution'.

Debugging JavaServer Pages

JavaServer Pages are converted into servlets and servlets are compiled to get the .class file. The Debugger maintains a one-to-one map of lines in the servlet that is created at compilation time to lines in the JSP. When a breakpoint is set in a JSP, the Debugger reads the map and sets the breakpoint in the corresponding line in the Servlet. Subsequently, breakpoint or step-in events return the appropriate lines in the JSP. This makes JSP debugging smooth.

Debugging Enterprise JavaBeans

EJBs allow to write complex business components in a single-threaded fashion though, inside the application server, the EJB runs in a multi-threaded environment.

A bean call invokes a function on a stub. Studio Debugger discovers calls made to bean methods and sets implicit break points in the bean code, automatically.

A thread re-directed from a breakpoint in the JSP to the bean code, hits the implicit breakpoint and pauses. This control flow to the method is similar to a Java step-into process.

Debugging on Oracle and WebLogic Servers

Applications deployed on Oracle and WebLogic Servers can also be debugged from inside Studio. For details. read `Working with WebLogic Server 6.1' and `Working with Oracle 9iAS'.

Disconnecting the Debugger

Click disconnect in the Debugger tool bar. This functions differently for different types of debugging:

For J2EE application is being debugged on a Server, using this option stops debugging the application, but does not stop the Server. One may restart debugging after disconnecting from the Server by using Debug > Start > Remote Debugging from the main menu and specifying localhost and 1234, as IP and port respectively.

In case of remote debugging, it stops debugging the remote application, but does not stop the remote application or the server. One may restart debugging the same remote application by specifying the IP and port as what was mentioned when the Debugger was initially started.

In case of other local debugging, it functions just like the Stop option. It stops the server.

Only one debugger can connect to an application running in debug mode

Thread scheduling is dependent on the OS. Potential dead lock situations cannot be predicted. Thread scheduling is different when the application is run in the debug mode. It is possible that the application executes as expected when it is traced in debug mode but not when it is run in non-debug mode