Home
.. Links
.. Search
.. Plugins
.. Help
.. Irc Faq

Projects
.. Platform/Faq
.. JDT/Faq/Plan
.. PDE/Faq
.. SWT/Faq
.. RCP/Faq

Tools Projects
.. CDT/Faq
.. GEF/Faq
.. EMF/Faq

Wiki Tutorials

Hosted Projects
.. MTJ
.. Google Summer Of Code 2007
.. Update Manager 2.0
.. EasyEclipse
.. Stylebase for Eclipse

Archives

DebuggingFaq


1) Q: I have problems executing code with a JVM other than the auto-detected machine (in my case 1.4.0). It does not even work when changing the default machine to 1.3.1, although the change is reflected in the perspectives. I.e., I see that JRE_LIB has changed to the 1.3 rt.jar location, but both Debug and Run ignore the setting.

A: You have to edit the run configuration. There are the settings for launching. But i would expect (didn't try) that the project jvm setting would override the run config.

2) Q : After changing the JVM for a particular project explicitly in the project settings, my breakpoints won't work anymore. Programruns all the way to the end. When resetting to the default machine,the problem persists. The only way to get debugging to work again is to erase the workspace.

A: I don't want to try that on my machine :), but sound like an error. Please add a bug at http://bugs.eclipse.org/bugs, would suggest jdt core. martin

3) Q: Every time I add a method to a class, the hot swapping feature fails.

A: This is actually a VM restriction, not a Eclipse restriction. Eclipse tries to hotswap the class, but the VM refuses.

I haven't used JDK's hotswap feature, but I have used J9's and it has similar restrictions. However you can add methods under some circumstances. In particular, you can add and remove private methods, static methods andconstructors. These methods don't affect the class's vtable, so the VMpermits them.
Hotswapping classes with added or removed virtual methods is certainly something that a VM could support, but it's more difficult than the non-virtual cases. [thanks to Peter Burka]

4) Q: Step over is acting like step return.

A: This is a problem on the Sun 1.4 vms. This problem has been tested to be fixed in the latest beta vms for 1.4.1. See bug 8441.

5) Q : Can I use older JDK's for debugging?

A: Eclipse cannot debug a program on anything less than 1.3 VM (on 1.2.2 with the correct dlls copied over from a 1.3 install). 1.1.8 does not support the protocols and interfaces that the eclipse debugger uses in communicating with the VM. You can run a program on 1.1.8 (as long as it is not Eclipse). Add a JRE using the Standard 1.1.X VM type. Create a launch configuration for you "main" class and specify that launch configuration to use the JRE you add. [Thanks Darin]

6) Q: Inspection or display of local variables may fail.

A: Usually it means that the concerned class was not compiled with debug enabled. Note that Sun's rt.jar is not delivered in a debug enabled version. You have to generate it by yourself.
Details from Darin:


The message is displayed when we make a request to the underlying
com.sun.jdi.StackFrame for the visibleVariables. If this call throws an
AbsentInformationException, we set that our JDIStackFrame does not have
locals available. This results in the message you see displayed.
The AbsentInformationException is thrown for native methods and for methods
that have been compiled without the required debug information.
[Thanks Darin again]

7) Q: How to debug code from rt.jar with JDK 1.4.1?

A: If you want to debug code from rt.jar you will get some information like "can't debug - absent line information."
This small howto will tell you how.
Create your own rt.jar (myrt.jar)
— create a directory (newruntime) with a src directory
— unzip the jdk source into the src directory
— create a new java project with the project contents directory newruntime
— let it compile - takes a while
— export as a jar file Create a new JRE configuration
— Prefrences >> Java >> Installed JREs >> Add
— Browse to the usual JRE home directory
— uncheck "use default system libraries"
— add myrt.jar as an external jar above rt.jar Verify
— While debuging check the command line ("Properties" page of the process in the debug perspective) to make sure that myrt.jar is on the boot classpath
— if not add myrt.jar to the bootclasspath on the commmandline in your run configurations: -Xbootclasspath/p:C:dir omy ewruntimemyrt.jar .

And another answer:

For the interested here a step-by-step explanation with script:

(1) The bottom line is:
* get the JDK source (i did it with version 1.4.1)
* get the original rt.jar for the same version
* unzip the rt.jar into a directory OriginalRT
* unzip the JDK source into a directory RTSource

(2) Now the fun starts:
* delete all files from RTSource that are NOT contained in OriginalRT
(apparently old classes, they do not compile ...)
* compile the rest of the java files in RTSource with the "generate debug
information" flag (and the RTSource directory, dt.jar, tools.jar and
htmlconverter.jar in the classpath)
* copy all compiled classes that are in OriginalRT but not in RTSource into
the corresponding place in RTSource
* jar RTSource into a file rt_debug.jar
* use rt_debug.jar instead of rt.jar in your classpath -> et voila!

I found a cygwin script on the web doing all the things described in (2),
here it is in case you want to use it (thanks to the original creator of the
script!):

#!/bin/sh

# Change these four paths = as required

# Base dir
JAVA_HOME=/cygdrive/c/j2sdk1.4.1

# Where src.zip was extracted
JAVA_SOURCE=/cygdrive/c/JavaSourceCompile/RTSource

# Where rt.jar was extracted
RT_CLASSES=/cygdrive/c/JavaSourceCompile/OriginalRT

# Where to put the compiled classes
OUT_DIR=/cygdrive/c/JavaSourceCompile/RTSource


# These are the required options for javac, do not change
OPTIONS="-g -nowarn -sourcepath . -d `cygpath -wp $OUT_DIR` -source
1.4 -target 1.4"
SEP=";"

CLASSPATH=$JAVA_HOME/lib/dt.jar$SEP$JAVA_HOME/lib/tools.jar$SEP$JAVA_HOME/li
b/htmlconverter.jar
JAVAC_HOME=$JAVA_HOME/bin

# Loop through each java file in the source dir
cd $JAVA_SOURCE

#${JAVAC_HOME}/javac -classpath `cygpath -wp $CLASSPATH` $OPTIONS
`cygpath -wp ./com/sun/corba/se/ActivationIDL/ActivatorHelper.java`

#/usr/bin/find -name "*.java" | while read JAVA;
#do
# echo $JAVA

# Is this file part of rt.jar, or is it an obsolete source file
# eg = com/sun/corba/se/internal/Interceptors/ThreadCurrentStack.java

# CLASS=`echo $JAVA | sed "s/.java/.class/g"`
# echo ${RT_CLASSES}/${CLASS}
# if [ -e ${RT_CLASSES}/${CLASS} ];
# then
# # Has this file already been compiled
# if [ -e ${OUT_DIR}/${CLASS} ];
# then
# echo Already compiled.
# else
# ${JAVAC_HOME}/javac -classpath `cygpath -wp $CLASSPATH` $OPTIONS
`cygpath -wp $JAVA`
# fi
# else
# echo Obsolete source file.
# fi
#done


# Now check for any files that are in rt.jar but not src.zip
cd $RT_CLASSES
/usr/bin/find . -type f | while read CLASS;

do
if [ ! -f ${OUT_DIR}/${CLASS} ]; then
echo Not found : $CLASS
# Uncomment this once the script has been run and all classes have
successfully compiled
# cp --parents $CLASS $OUT_DIR
fi
done

That runs for a while, because it's quite some amount of classes - but it
works!

8) How doing remote debugging?


Last Modified 6/21/06 10:28 AM

Hide Tools