cattails

Blue Marsh Softworks

 Site Index
 o java projects
 o about me
 o search

 My Java
 o java tips
 o java faq
 o contributing
 General Java
 o JavaSoft
 o Developer Connection
 o The Java FAQ
 o Java Glossary

 JSwat
 o download
 o documentation
 o faq
 o mail lists
 o contributing
 o bugs
 Related Software
 o JPDA
 o Emacs JDEE
 o JDBTool
 o jEdit plugin
 o Jenus
 o NetBeans
 Related Links
 o Top Ten Reasons Not to Use a Java Debugger in School

Frequently Asked Questions

The following are a list of frequently asked questions about both the JSwat project and the Java Platform Debugger Architecture. You may want to check out my Java FAQ page as well.

About Questions

  1. How is JSwat used? What is the JPDA and what role does it play?
    JSwat is a Java application which utilizes the classes provided in the Java Platform Debugger Architecture. JPDA provides the back-end support for debugging Java classes. To use JSwat you will need a JDK and the JPDA installed on your system. See the README.html file distributed with JSwat for the details.
  2. Which version of the JDK and JPDA should I be using to run JSwat?
    See the downloads page for the program requirements.

Setting Up, Starting Questions

  1. When I start JSwat I get an error about the JIT compiler.
    You cannot debug using the JPDA with the JIT compiler turned on. You can turn off the JIT compiler by passing the "-Djava.compiler=NONE" switch to java when starting JSwat and/or your application. You could also define the environment variable JAVA_COMPILER, setting its value to "NONE". JDK 1.4 and later do not support the flags described above. Instead, ensure that the HotSpot flags are not being used when launching the debuggee (-client, -hotspot, or -server).
  2. When I start JSwat and try to load a class to debug, I get the error "can't load 'jdwp.dll'".
    You need to make sure the JPDA 'lib' directory is in your PATH environment variable. In this case, the 'jdwp.dll' file is missing from your PATH and the JVM cannot find the file when JPDA initializes. Locate the directory containing the 'jdwp.dll' file and make sure that is in your PATH.
  3. When I start JSwat and try to load a class to debug, I get the error "can't load 'libjdwp.so'".
    You need to make sure the JPDA 'lib/i386' or 'lib/sparc' directory is in your LD_LIBRARY_PATH environment variable. In this case, the 'jdwp.dll' file is missing from your LD_LIBRARY_PATH and the JVM cannot find the file when JPDA initializes. Locate the directory containing the 'jdwp.dll' file and make sure that is in your LD_LIBRARY_PATH.
  4. When I try to start JSwat like so "java -jar jswat.jar", it fails. It prints a message "Missing JPDA package."
    Please read the README.html file included with JSwat for the instructions on how to start the program.
  5. When I launch my program in JSwat it has problems, but it runs fine without JSwat.
    If you are running on a Windows platform, try the steps given here, under the heading of the "JDK versus JRE".

Using Questions

  1. When I type 'resume' to begin running my program from within JSwat, the debugger seems to hang.
    You are probably running the HotSpot VM in JDK 1.3 on Linux. The HotSpot VM in JDK 1.3 is not very good for debugging and you should use the Classic VM instead. See the Run Classic VM page.
  2. When I try to start my debuggee class with the "load myClass" command, it fails, saying the debuggee VM exited.
    If you check the "Output" panel in the JSwat window. You will probably see a message that says the class was not found. You need to set the classpath properly before launching the debuggee.
  3. When I single step over a method that attempts to read input from the standard input, the call hangs.
    Press the Refresh button and that will unblock JSwat. For some reason on green threaded systems, JSwat hangs when attempting to send input to the debuggee VM. It works fine on Windows systems and in JDK 1.4 and later.
  4. The thread status seems to always say "UNKNOWN".
    This seems to happen with older HotSpot VMs. Try running JSwat and your debuggee VM with the Classic VM (see the Run Classic VM page).
  5. Debugging seems very slow, especially the startup time of my program.
    Are you running the HotSpot VM on a JDK earlier than 1.4? If so, turn it off. It can greatly affect the run time of your program during debugging. See the Run Classic VM page. In JDK 1.4 and later, the HotSpot VM is the only VM available. Make sure you are not using any of the HotSpot flags (-client, -hotspot, or -server). You might also try remotely debugging your program. Start the program and attach to it remotely after it has completed its startup. This is described in the help files provided with JSwat.
  6. I cannot get JSwat to show me the values of any variables. It seems that JSwat thinks there is "no variable information for that class".
    Recompile your classes with the -g option. This turns on the debugging information when the compiler generates the .class files. This is necessary for any Java debugger that you would use.
  7. Some local variables seem to be invisible to the debugger. The code compiles and runs fine, but the debugger is unable to display the variables.
    It is unclear if the Java compiler or the Java VM is at fault here. Either way, the solution tends to be the same -- assign an initial value to the variable when you define it. That is, instead of "String s1;" you would write "String s1 = null;". This makes the variable appear to the debugger.
  8. JSwat tells me that it cannot find my source files. Why is that?
    JSwat uses the classpath and sourcepath to locate source files. Check that these are set with appropriate values. Read the Classpath and Sourcepath help topic to learn all about the classpath and sourcepath.
  9. I am getting "Exception thrown... CharToByteSingleByte.convert" when I launch the debuggee from within JSwat.
    You probably are running a Unix-like system and are missing the URW fonts. See http://www.gimp.org/fonts.html for the freely available URW fonts.

Breakpoint Questions

  1. Setting breakpoints seems to be failing.
    Older versions of HotSpot seem to have a couple of major flaws, handling breakpoints is one of them. Try running JSwat and your debuggee VM with the Classic VM (see the Run Classic VM page).
  2. I am having trouble setting breakpoints in a particular class. It seems that JSwat thinks there is "no line number information for that class".
    This may be caused by the java compiler. If you are using jikes, it could be generating invalid debugging information. Try using the Java compiler that comes with the JDK. Additionally, I find that deleting all the class files and recompiling will sometimes help.
  3. I keep getting "no code at that line" messages when starting the debuggee.
    This is likely caused by a breakpoint that was set on a line of code that has moved to another line. That is, you set a breakpoint at line X, then modified the code so that the code at X is now at Y. Meanwhile JSwat keeps trying to resolve the breakpoint at line X. Simply delete or edit the breakpoint specification to resolve this issue.

Console Questions

  1. When using JSwat via the console mode, I cannot enter very long commands, such as to set a long classpath. It seems to limit to 256 characters.
    It seems that on Solaris, the terminal driver is set to only allow canonical input lines of up to 256 characters. You may need to use a different terminal emulator or command interpreter to avoid this issue.
© Copyright 2000-2002 - Blue Marsh Softworks