- 1.0 INTRODUCTION
- 2.0 INSTALLATION
- 2.1 General remarks
- 2.2 Installation on Windows®
- 2.3 Installation on Linux and Linux/390
- 2.4 Installation on AIX
- 2.5 Installation on Solaris
- 2.6 Installation on OS/2
- 2.7 Installation on OS/390
- 2.8 Installation on HP-UX
- 2.9 Installation for use with WebSphere Application Server v3.5 (Fixpack 3 or higher)
- 3.0 UNINSTALLING
- 3.1 Uninstalling on Windows
- 3.2 Uninstalling on Linux
- 3.3 Uninstalling on HP-UX
- 4.0 DEBUGGER ISSUES AND LIMITATIONS
- 4.1 Debugging applets in a browser
- 4.1.1 Internet Explorer for Windows
- 4.1.2 Netscape for Windows
- 4.2 General issues
4.2.1 TCP/IP considerations
4.2.2 Windows-specific issues
4.2.3 AIX-specific issues
4.2.4 AS/400-specific issues
4.2.5 Solaris-specific issues
4.2.6 Usage tips, limitations, and known issues
4.2.7 Generating Business Object code for tracing and debugging in Object Builder- 4.3 Limitations for Java (interpreted only)
- 4.3.1 General issues
- 4.3.2 JDK and CLASSPATH issues
4.3.3 Interpreted Java- 4.3.4 JavaServer Pages (JSPs)
- 4.4 Limitations for all compiled languages
- 4.4.1 General issues
- 4.4.2 AIX-specific limitations
- 4.4.3 OS/390-specific issues
- 5.0 OBJECT LEVEL TRACE KNOWN ISSUES AND LIMITATIONS
- 5.1 OLT online documentation issues
- 5.2 NL- and GUI-related limitations and considerations
The IBM Distributed Debugger and Object Level Trace support debugging and tracing on AIX, OS/2, Solaris, Windows NT and 2000, OS/390, HP-UX and various distributions of Linux. The debugger can debug both interpreted and compiled Java, as well as other compiled languages, such as C++. Please see the chart below for further details.
National Language Support has been provided for Group 1 (Gr1) languages, which are Brazilian Portuguese, English, French, German, Italian, Japanese, Korean, Simplified Chinese, Spanish, and Traditional Chinese.
The S/390 server series and the OS/390 operating system are now called the IBM eServer zSeries and zOS respectively. However, for the purpose of this document, all reference made to the server and operating system will be by their former names, S/390 and OS/390.
The AS/400 server series is now referred to as the IBM eServer iSeries or IBM eServer iSeries 400. However, for the purpose of this document, all reference made to the server will be by its former name, AS/400.
The following table presents a summary by platform of Debugger and OLT functionality on supported platforms, and the languages for which National Language Support has been provided. For the earliest supported operating system level, please refer to product installation information.
Platform | AIX | OS/2 | Solaris | Windows NT/2000 | OS/390 | OS/400 | Linux | Linux390 | HP-UX |
Debugger User Interface (idebug) | X | X | X** | X+ | |||||
Debugger Engine Interpreted Languages (irmtdbgj) | X | X | X | X | X | X | X | X | |
Debugger Engine Compiled Languages (irmtdbgc) | X | X | X | X | |||||
National Language Support | Gr1 | Gr1 | Gr1 | Gr1 | * | Gr1 | Gr1 | * | Gr1 |
OLT | X | X | |||||||
OLT Java runtime | X | X | X | X | X | X | X | X | |
OLT C++ runtime | X | X | X | X |
* English and Japanese on host; Group 1 on client.
** For OS/390 remote debugging, use the idebug command on the workstation to start a Debugger user interface daemon that will connect to Debug Tool or the Java debug engine on the host (OS/390).
+ For AS/400 remote debugging, use the idebug -a command on the workstation to start the Debugger user interface and ensure that the STRDBGSVR command was issued on the AS/400 server.
The following table lists the platforms that supports debugging interpreted Java programs using JDI (Java Debug Interface) and the corresponding JDK levels.
Platform |
AIX |
OS/2 |
Solaris |
Windows NT/2000 |
OS/390 |
OS/400 |
Linux |
Linux390 |
HP-UX |
---|---|---|---|---|---|---|---|---|---|
JDK level | 1.2.2 SR11 or later
and 1.3.0 SR6 or later |
1.2.2_007* or later
and 1.3.0 or later |
1.2.2 SR9 or later
and 1.3.0 SR5 or later |
1.3 SR6 or later | 1.1.8 or 1.2 or 1.3 | 1.2.2 SR9 or later
and 1.3.0 SR5 or later |
1.2.2 SR9 or later | 1.3.0 or later |
* JPDA support must be installed separately for JDK 1.2.2_007 or later. JPDA is available from Sun Microsystems at http://java.sun.com/products/jpda/download.html.
The following remarks regarding installation and prerequisites are applicable to all platforms for the installation of the IBM Distributed Debugger and Object Level Trace tools. Additional prerequisites and platform-specific installation issues are mentioned in the subsections for each platform.
General prerequisites:
Netscape Navigator, Version 4.5 or later is recommended for displaying Debugger and OLT online help. Using an earlier version may give you a browser exception if you reopen a help window multiple times.
For interpreted debugging, the following additional prerequisites apply:
Prerequisites:
For standalone debugging, the location of the Java executable specified in the PATH environment variable must be from the JDK \bin directory. For example, if, on Windows NT, the PATH environment variable points to the java.exe file in the \WINNT\SYSTEM32 directory, the Debugger cannot debug the application. To avoid this problem, insert the full path to java.exe in the JDK \bin directory to the start of the PATH environment variable.
If you are using remote stored procedure debugging on DB2, you must add the \IBMDebug\lib\dertrjrt.jar file to your system CLASSPATH.
Installation:
Installing the Distributed Debugger on Windows is automatic and does not require you to manually issue any commands or move any files.
Any beta version of the IBM Distributed Debugger must be uninstalled before installing the current version that accompanies this product. See Section 3.1, Uninstalling on Windows.
The Debugger will not function if installed in a directory whose name contains spaces or DBCS characters.
The Distributed Debugger ships a Java debug engine for Linux/390. Linux/390 images are of the form DERJPICL-9-0.s390.rpm, whereas the standard Linux/Intel images are of the form DERJPICL-9-0.i386.rpm. These images are not interchangeable between platforms, but install and operate in a similar manner.
Installation:
Prerequisites:
If you are using remote stored procedure debugging on DB2, you must add the /usr/lpp/idebug/lib/dertrjrt.jar file to your system CLASSPATH.
Before you can run OLT on AIX, you must execute OLT.profile from within your .profile script.
Installation:
Search for the install image of the Distributed Debugger. Copy the install file(s) to the machine on which the Debugger is to be installed. Use installp or smitty install_latest.
Prerequisites:
If you are using remote stored procedure debugging on DB2, you must add the /opt/IBMdebug/lib/dertrjrt.jar file to your system CLASSPATH.
If you are using a locale other than en_US, you must add /opt/IBMdebug/msg/%L/%N to the NLSPATH environment variable.
Installation:
If you are using JDK 1.2.2 for debugging applications on Solaris, you need to do the following:
Prerequisites:
Interpreted Java debugging is supported only for Java programs developed for JDK 1.1.8 or lower.
Installation:
Search for the install image of the Distributed Debugger. The following copies the install file(s) to the machine on which the Debugger is to be installed. You will also need to set environment variables.
To install on OS/2:
- Choose a drive on which to install the Debugger Engine.
- Create a directory called \IBMDebug.
- Change directory (by issuing the cd command) to \IBMDebug.
- Unzip the Debugger zip file.
Setting Environment Variables for OS/2:
- Add d:\IBMDebug\bin to the PATH environment variable, where d is the drive on which the Debugger resides.
- Add d:\IBMDebug\dll to the LIBPATH environment variable or to the BEGINLIBPATH environment variable.
- Add d:\IBMDebug\help to the DPATH environment variable.
- Add d:\IBMDebug\msg\%L\%N to the NLSPATH environment variable.
- Add d:\IBMDebug\locale to the LOCPATH environment variable.
Note: To make these changes permanent, modify the environment variable settings in the CONFIG.SYS file.
Prerequisites:
These prerequisites require you to know the version number of the Distributed Debugger (for use as a client) you are using. To obtain the version number, issue the idebug command at a Windows command prompt and examine the Command Prompt window to see the copyright and version message.
If you install the VisualAge for Java PTF for OS/390, you must ensure that you are running the Distributed Debugger user interface, version 8.4.3 or later. Version 8.4.3 can be downloaded from IBM VisualAge Developer's Domain at http://www.ibm.com/vadd.
The IBM JDK 1.3 SR6 (Service Release 6) is a prerequisite for interpreted debugging on this platform. You can download this JDK from http://www-1.ibm.com/servers/eserver/zseries/software/java/.
Version 8.4.3 or later of the Distributed Debugger user interface requires either of the following Debug Tool PTFs:
- 09/1999 DT PTF (EQAW.SEQAMOD)
- 03/2000 DT PTF (Y2000.M05.D09 DT)
Installation:
To install the Distributed Debugger on your OS/390 server, do the following:
- Create the following directory structure:
/usr
/usr/lpp
/usr/lpp/IBMDebug
/usr/lpp/IBMDebug/lib
/usr/lpp/IBMDebug/bin- Once the directories are created, use ftp to copy the following binaries from the machine on which you have installed the Distributed Debugger user interface to their corresponding locations on the OS/390 server:
Copy /extras/390/bin/irmtdbgj to /usr/lpp/IBMDebug/bin/irmtdbgj
chmod +x irmtdbgj
Copy /extras/390/lib/derdebug.jar to /usr/lpp/IBMDebug/lib/derdebug.jar- Prepend /usr/lpp/IBMDebug/bin to your system path.
The Debugger engine can then be started using the irmtdbgj command.
Prerequisites:
Java Version 1.3 is required for installation and Java debugging.
Installation:
To install the Distributed Debugger, do the following:
- In the HP-UX archive, there will be an install.class file.
- Issue the java install command.
This section applies to installation of the IBM Distributed Debugger and Object Level Trace for use with WebSphere Application Server, Advanced Edition Version 3.5.3 or higher, but not Version 4.0 or higher. To install, do the following:
If the application server is running on Solaris, do the following:
The parent products of the IBM Distributed Debugger may depend on it being installed. For most platforms, the IBM Distributed Debugger uninstalls along with the uninstall of the product it accompanied. This is the recommended uninstall procedure.
The manual procedure for uninstalling the Debugger is provided for removal of beta versions on the Windows platform.
The following sections discuss platform-specific uninstall issues.
The Add/Remove Programs utility in the Control Panel will not uninstall only the Distributed Debugger while keeping the parent product. On the Windows platform, the Debugger can only be uninstalled by uninstalling the parent product.
VisualAge for Java, Version 3.0 only:
If you installed the Distributed Debugger along with this product, you must uninstall the Debugger before attempting to uninstall the product. If you uninstalled VisualAge for Java, Version 3.0 without removing the Debugger first, you can still uninstall the Debugger by manually deleting the registry key that contains the name of the product: HKEY_LOCAL_MACHINE\SOFTWARE\IBM\IBM Distributed Debugger\CurrentVersion\Install\ParentProducts\VisualAge for Java for Windows.
Note: Any deletions from the Windows registry other than those identified may render your system unstable or unusable.
Removing installed beta versions of the Distributed Debugger:
The following procedures are provided to allow you to remove the Debugger from your system by manually editing the Windows registry.
To remove the IBM Distributed Debugger, do the following:
- Run regedit.exe.
- Backup your registry file by exporting your registry file.
- Go to HKEY_LOCAL_MACHINE\SOFTWARE\IBM\IBM Distributed Debugger\CurrentVersion\Install.
- The RefCount entry indicates the number of Debugger instances on the system. Decrement the RefCount value data by 1.
- Click on the Uninstaller icon of the newer (non-beta) version of the Debugger. This should uninstall the icons and files (if there are no other IBM products installed on your machine that make use of the IBM Distributed Debugger).
- If the RefCount value data is equal to one, remove the HKEY_LOCAL_MACHINE\SOFTWARE\IBM\IBM Distributed Debugger registry key, if it exists. If the RefCount value is less than one, set it equal to one and re-try the uninstall.
The uninstall process is complete if the RefCount entry is not equal to one.
To reinstall the IBM Distributed Debugger, use the product CD to install it with the parent product.
To uninstall the IBM Distributed Debugger, do the following:
To uninstall the IBM Distributed Debugger, issue the following command:
juninst <Destination Directory>/UnInst
where <Destination Directory> is the root of the debugger install tree. For example, juninst /opt/ibm/debugger/UnInst.
Changes to the JDK necessitated the following browser configurations in order to debug applets in a browser.
4.1.1 Internet Explorer for Windows
- Requires Internet Explorer 4.0 or later.
- Ensure you have a JDK installed on your system before performing these steps.
- In order to debug applets inside Internet Explorer, you must install the Java(TM) Plug-in 1.1.1 or later, available from http://www.javasoft.com. You must also configure your HTML pages to use the modified applet tag format.
- Close all browsers.
- Start the Java Plug-in Properties panel.
- Click the Advanced tab.
- Click the Enable Debug checkbox.
- Select a port (default is 2502).
- Set the Java Run Time Environment to point to your JDK install directory (you cannot use the plug-in's JRE).
- Click Apply.
- Start the applet in your browser.
- A dialog box will appear with the agent password. Make note of this password and click OK.
- From a command line, set your CLASSPATH to include the applet's class/source files. Issue the following commands on OS/2, AIX, or Windows:
irmtdbgj -quiport=<port> -qhost=<hostname> -password=<agent password>
The Debugger will attach to the applet running inside the browser.
- Requires Netscape 4.5 or greater.
- Follow the instructions in Section 4.1.1, Internet Explorer for Windows with the following modifications:
If you wish to debug more than one applet on the same system or if port 2502 is being used by another application, you may use the following port/password pairs:
Port in Plug-In Panel Agent Password for idebug 2502 52fd4n 2503 527dkr 2504 4k6h32 2505 44edjc 2506 5ifdjf 8003 3kyt2g 8004 44rtii 8005 54rtik 8006 4kyxkx
The Debugger (and many other Java products) requires TCP/IP to be functioning and that you be able to ping your own machine hostname (or the localhost hostname), even while disconnected from a LAN.
- On Windows 2000, in order to use the context-sensitive help of the accompanying product, you need to define a system environment variable called windir and set it to the system root. For example, if your system's root is c:\winnt, then windir=c:\winnt.
- To avoid intermittent hangs on Windows 2000, try disabling the Windows Active Desktop. To disable the Active Desktop, do the following:
- Right-click on your Windows desktop to invoke the Display Properties dialog box.
- In the Web tab, de-select the Show Web content on my Active Desktop checkbox.
- Windows NT and 2000 have a limit on the length of command lines (2100+ chars). The idebug command typically uses about 350 characters, and so you should ensure that the CLASSPATH environment variable is less than 1750 characters. Results are unpredictable when the combined length of a command and CLASSPATH exceeds this 2100-character limit.
- If, on Windows NT, you receive an error message about not being able to locate CPPWMTHI.DLL, you should change the setting of the LOCPATH so that %LOCPATH% appears as the first value in the Value field. Set the LOCPATH environment variable in the User Variables section of the Environment page of the System Properties window. This ensures that you will pick up the System LOCPATH value.
- If the Debugger user interface (invoked by issuing the idebug command) displays the message Cannot create XXXX server socket (where XXXX represents a port number), there may be an old java process still running. Use the Windows NT Task Manager to end it.
- When debugging a GUI application on Windows, the debugger may hang when help is requested. To correct this problem, do one of the following:
- If you are using Internet Explorer: Set debugger application preferences so that help is displayed in the same browser window for each help item that is requested, and then start Internet Explorer before requesting help from the debugger. To set the debugger to display help in the same browser window each time help is requested, select File > Preferences > General > Help from the debugger main menu and select the Open help in a separate browser window checkbox.
- If you are using Netscape: Run or step the GUI application that you are debugging, and the help will appear.
- If the debugger is unresponsive, except for an alert noise when you click the debugger user interface, try using the keyboard to request a dialog box (for example, type CTRL+L to invoke the Load Program dialog box) and then cancel the dialog box.
- When using the Help section of the Application Preferences dialog box (select File > Preferences > General > Help from the debugger main menu), regardless of entries made in the Help Browser and Browser Location fields, your system's default browser may be used when help is launched.
- If running the user interface (invoked by issuing the idebug command) results in the message "killed" and the user interface does not come up (or shuts down) the likely cause is insufficient system pagefile space.
- If the LIBPATH environment variable contains /usr/lib, ensure that /usr/lib/threads appears before /usr/lib.
- If Run To Completion hangs in a WebSphere Application Server Enterprise Edition environment, you should terminate the client application.
- If you attach to an AS/400 job without specifying the name of the program to debug and run your application to completion, you will not get notified of the application completion. At this point, you can either invoke the Attach or Load Program dialog box to start a new debug session, use the Halt button to terminate the current debug session, or terminate the debugger user interface using File > Exit from the debugger menu bar.
- When debugging an AS/400 application and using the Source > Change Text File option, specify either a valid local file, or * to use the original AS/400 source file. If you specify an invalid source file name, the displayed view may become corrupted.
- If you examine or retry a signal that occurs in a multithreaded debuggee and then run, the signal will reoccur when the thread that generated it terminates. In this situation, the signal cannot be run or discarded. To escape, you must terminate the debuggee.
4.2.6 Usage tips, limitations, and known issues
- When you launch help from the Distributed Debugger, you can choose to have the help displayed in a separate browser window for each help item requested, or you can choose to have the same browser window display each help item as it is requested. To set your preference for this behavior, select File > Preferences > General > Help from the debugger main menu and select or de-select the Open help in a separate browser window checkbox.
- Allow the debugger to complete operations while the busy cursor displays, before clicking in any debugger windows.
- If the Debugger user interface is terminated, then the Debugger engine (derdfsrv or derdewd) or the java process may need to be terminated manually. If any of these processes are running when you attempt to restart the Debugger (with the idebug command), the attempt may fail.
- If you attempt to load an invalid program and then close the starting dialog, the Debugger will still attempt to load the invalid program. After the timeout, a "load failed" message will appear, even if you have subsequently loaded a valid program.
- Editing text values in the various panes requires you to press Enter when done. Clicking elsewhere in the pane without first pressing Enter will cancel the editing.
- If you catch an exception and choose to run the exception, the Debugger user interface will no longer respond unless your application hits a breakpoint, runs to completion, or throws another exception.
- Changing the toolbar settings (File > Preferences > General > Appearance, Toolbars) may cause erratic Debugger behavior. If you have changed them and want to restore the default settings, delete Workbook*.ini and Panes.ini in your DbgProf profile directory. This also applies for remote debugging of OS/390 applications from Windows NT.
- Some Unicode characters, such as \u03a9, do not display correctly. The Debugger currently cannot tell if a given character is displayable in the current user font set.
- Using the debugger help when debugging Java AWT applications may cause the Debugger to hang.
- Using a larger font (File > Increase Font) may cause some text to be truncated. To address this problem, either use a smaller font or restart the Debugger, which allows all components to adjust to the larger font.
- If a storage or storage monitor view continues to scroll after you have stopped clicking the left mouse button, then click again either above or below the slider to cause a single scroll in the opposite direction.
- An error message may appear with the message Invalid object if your mouse is moved over a deferred monitored expression (an expression that comes from a module which has been already unloaded) in the Monitors view. This message can be ignored.
- If you are running the Distributed Debugger user interface on AIX and F1 help calls do not result in help appearing in your Netscape browser, upgrade your Netscape version to 4.74 or higher.
- Tool tip evaluation uses spaces and punctuation to parse source and, therefore, will only evaluate identifiers and not expressions. If you wish to evaluate more complicated expressions with tool tip, highlight the entire expression in the Source view and then position the mouse pointer to hover over the highlighted expression and see the evaluation.
- When viewing a Control or Value pane with expandable items, choosing the Expand All option from the pane's menu in the debugger main menu bar will expand one level of the tree at a time. You must choose Expand All for each subsequent level of the tree that you wish to expand. Choosing Collapse All will collapse all levels of the tree.
4.2.7 Generating Business Object code for tracing and debugging in Object Builder
By default, the wrapper code that is code-generated in Object Builder is compiled with debugging flags turned on. This causes the Distributed Debugger to interpret it as debuggable. To limit debugging to business logic only, follow these steps:
- Build with IVB_UNOPTIMIZE=1, ensuring that there are no make options for any of the individual build configuration units. By default, this should create non-optimized, non-debug-enabled binaries in the NOOPT subdirectory.
- Touch any Object Builder-generated files for which you wish to have debug information compiled.
- In the build configuration unit's SmartGuide, add the make option, IVB_TRACE_DEBUG=1, and regenerate the all.mak makefile from the build configuration main folder.
- Build with IVB_UNOPTIMIZE=1 again as in Step 1 above. This will build the touched file(s) with trace and debug information and link these binaries with the non-optimized, non-debug versions created in Step 1. The results will be in the NOOPT subdirectory.
The Debugger provides two different ways of stepping into a method when debugging interpreted Java:
- Step Into, which will step into the specified method regardless of the package the method is in.
- Step Debug, which will only step into methods which are not in the following default filtered packages:
java.*
javax.*
sun.*
com.sun.*
com.ibm.*
org.omg.*
org.xml.*
org.w3c.*In order to change the list of filtered packages, you can pass the option -qfilter=filteredPackageList to irmtdbgj or irmtdbgc, where filteredPackageList is the name of the file that includes the list of packages not to be debugged by the users of your application.
4.3.2 JDK and CLASSPATH issues
The product install does not check for the prerequisite JDK. You should ensure it is installed and configured (PATH and CLASSPATH are set correctly) so that the java command works from the command line.
If you do not have an installed JDK and you attempt to debug an interpreted Java application either locally or remotely, you may get an error message from the irmtdbgj executable, to the effect that it cannot find the java executable.
The Debugger does not detect invalid JVM arguments. If any JVM arguments that are provided for debugging an application are invalid, the Debugger may either exit upon this failure or hang. Please refer to the section "SDK Tool Documentation" of your installed JDK for the complete list of valid JVM options.
General issues:
- If you cannot monitor variables or see your locals, then ensure that you have compiled your .java files with the -g option to turn on full debugging information.
Java 2 JDK-related issues:
- Starting a Java program for the purpose of attaching to that program is done differently on the Java 2 platform than it is for JDK 1.1.X
- For JDK 1.1.X, use the following command:
java_g -debug <classname and args>- On the Java 2 platform, use one of the following commands:
- If you have installed the JDK 1.2.2 SR9 or higher service release, the command is:
java -Xdebug -Xnoagent
-Djava.compiler=NONE
-Xrunjdwp:transport=dt_socket,server=y,suspend=n -Xbootclasspath/a:\lib\tools.jar;\lib\derdbpw.jar <classname and args>- If you have installed the JDK 1.3, the command is:
java -Xdebug -Xnoagent
-Djava.compiler=NONE
-Xrunjdwp:transport=dt_socket,server=y,suspend=n <classname and args>Note: If you are running on HP-UX, you also need to add the -classic option as the first option to the java command, i.e. java -classic -Xdebug -Xnoagent.
This command causes the java run time to create a random-generated port number listening for a connection and a message similar to Listening for transport dt_socket at address: 4716, where 4716 is a random generated port number provided by the Java runtime.
If you wish to provide a specific port number (for example, XXXX), the -Xrunjdwp suboption list must change to -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=XXXX. For more information on -Xrunjdwp suboptions please refer the section "Connection and Invocation Details" of the Java Platform Debugger Architecture (JPDA) document of your installed JDK.
- Avoid using watchpoints with JDK 1.2.2 SR9, which causes the JVM to crash. This is resolved in JDK 1.2.2 SR10 and JDK 1.3.0.
- If you are using JDK 1.2.2 Service Release 9 or above, or JDK 1.3, and you started your JVM with the command:
java -Xdebug -Xnoagent
-Djava.compiler=NONE
-Xrunjdwp:transport=dt_socket,server=y,suspend=y -Xbootclasspath/a:\lib\tools.jar(that is, you are attaching to a suspended JVM), the Debugger will not display your code because the JVM has not yet loaded the main class. In order to run to main(), set a deferred method breakpoint on main(), specifying the name of the class that contains main(), and then click the Run button to run to the breakpoint. See the online documentation for more information on setting deferred breakpoints.
- If you are using JDK 1.2.2 Service Release 9 or above, or JDK 1.3 Service Release 6 or below on AIX, then exceptions cannot be caught by the debugger (due to a JDK problem). This problem is fixed in JDK 1.3 Service Release 7 and above.
Debugger limitations:
- When using JDK 1.2.2 SR9 or later on AIX, avoid putting breakpoints on lines of code that access static members. Because of a JDK problem, any such breakpoint will only be hit the first time that line of code is reached. If you encounter this problem, try setting the breakpoint on another line.
- When using JDK 1.3 or above on Solaris, avoid putting breakpoints on lines of code that reference constants. Because of a JDK problem, any such breakpoint will only be hit the first time that that line of code is reached. If you encounter this problem, try setting the breakpoint on another line.
- When using a JDK level lower than JDK 1.2.2 SR9, you can Step Debug into a constructor only if you have set a breakpoint in the constructor prior to issuing a Step Debug command.
- If you are using JDK 1.2.2 prior to service release 9 or JDK 1.1.x, you cannot modify the contents of a local variable from the Locals pane. This problem has been resolved in JDK 1.2.2 SR9 or higher and in JDK 1.3.
- Debugging a program that reads from standard input is not supported and will cause the Debugger to hang.
- Console input is not accepted.
- You cannot suspend or stop threads.
- Some non-English characters do not display correctly in the Debugger console window ("System.out").
- Breakpoints set on try statements will be ignored.
- Monitoring a variable on its declaration line will fail. You must click on the variable within its scoping block.
- The Debugger notifies of exceptions that are extended from java.lang.Exception, but not from java.lang.Error.
- After exiting a program block, variables that are out of scope may still be shown in the monitor. This is a JDK problem.
- Stepping behavior may be erratic when stepping into constructors, or when stepping into or over SystemLoad library functions.
- When stepping over a statement which causes an exception to be thrown, the Debugger will not always correctly step into the catch block for the exception.
- If you step into a class for which the Debugger does not know the location of its source (such as java.lang.String), you may receive a No Source Available message. If this happens, issue a step return command to return to the class for which you did have the source. You can avoid this problem if you can provide the location of the source (either relative to the rest of the classes in the application or an fully qualified path of that source) in the Source File Name dialog box.
Remote debugging considerations:
- When running your Debugger remotely and the source files reside on the machine where you are running the Debugger user interface, set the DER_DBG_PATH environment variable to include your source files.
- When debugging remotely using irmtdbgj in Windows NT, if the -classpath value passed to the -jvmargs option has a space, the Debugger will not be able to launch a JVM for the application. In order to avoid this problem you can do one of the following:
- add the classpath information to the CLASSPATH environment variable instead of to the -jvmargs option.
- add \\\" (three backslashes plus quotes) around the classpath information passed to the -jvmargs option. For example, irmtdbgj -jvmargs="-classpath \\\"c:\Program Files;d:\test\\\" -mx32".
Local debugging considerations:
When debugging locally using idebug, if the -classpath value passed to -qjvmargs option has a space, the Debugger will not be able to launch a JVM for the application. In order to avoid this problem, add \\\" (three backslashes plus quotes) around the classpath information passed to the -qjvmargs option. For example, idebug -qjvmargs="-classpath \\\"c:\Program Files;d:\test\\\" -mx32".
When debugging JavaServer Pages, you may step to HTML lines, however, you cannot step to or into in-line Java code. Variables declared in in-line Java code blocks may be inspected.
For example, given the following JSP fragment:
<%
java.lang.String _s1 = "<B>Hello</B>"; java.lang.String _s2 = " world!"; %>
<%= _s1 %>
<%= _s2 %>you cannot step into the in-line java code (included in the <% %> tags) but can add the variables _s1 and/or _s2 to the program monitor list.
The Debugger does not allow the monitoring of an expression that uses the this pointer, such as this.x, where x is a member of a class. Use x instead.
4.4.2 AIX-specific limitations
A Halt action can be performed on the program you are debugging by opening another window on the machine on which the program you are debugging is running, finding the process ID of the program you are debugging using the ps(1) command, and then executing the kill -STOP <pid> command, where <pid> is the process id of the program you are debugging. This can interrupt long-running execution actions such as step-debug.
- The S/390 server series and the OS/390 operating system are now called the IBM eServer zSeries and zOS respectively. However, for the purpose of this document, all reference made to the server and operating system will be by their former names, S/390 and OS/390.
- All issues listed in this section pertain to remote debugging OS/390 applications on Windows NT.
- If you are using the user interface (idebug command) on Windows NT, the message Cannot create XXXX server socket (where XXXX is a port number) may be the result of an old java or java_g process that is still running. Use the Windows NT Task Manager to end it.
- If you catch an exception and then choose to run it, the Debugger UI will no longer respond unless your application hits a breakpoint, runs to completion, or throws another exception.
- To change the Debugger defaults, load any application, change the settings, select the Debugger Defaults checkbox, and then exit the Debugger.
- Some Unicode characters, such as \u03a9, do not display correctly. The Debugger currently cannot tell if a given character is displayable in the current user font set.