Skip to main content
Jump to: navigation, search

Debugging Eclipse GCJ Problems

Revision as of 16:11, 3 October 2006 by (Talk | contribs) (initial commit)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Debugging Eclipse GCJ problems

This tutorial explains how to track down GCJ problems in Eclipse. It was written using Eclipse 3.2.1 on Fedora Core 6 but you should be able to follow along with other versions of Eclipse and other distros.

  1. The first thing you need to do is to find out if you have a GCJ problem or not. Just run your test case with GCJ and Sun's VM to see if the problem only occurs with GCJ. If the problem only happens with GCJ, continue with this tutorial. Otherwise, file a bug in your distribution's bug tracking system or in the Eclipse bugzilla.
  1. Next you need to determine which plugin is causing the problem. A stack trace will give you clues as to which plugin is causing the problem. Once you know this you have to ascertain if the problem is a native compilation bug or a class library problem. Disabling the plugin's native library and re-running your test case will help you determine this. Just move <plugin-name-and-version> and <plugin-name-and-version>.jar.db from /usr/lib/gcj/eclipse to a temporary location and run rebuild-gcj-db. For example, if I were looking at a problem with org.eclipse.update.core_3.2.1.v20092006, I would run the following command:
sudo mv /usr/lib/gcj/eclipse/org.eclipse.update.core_3.2.1.v20092006.jar{.so,.db} /root
sudo rebuild-gcj-db

If the problem is now fixed, you need to file a bug against GCJ. You may be asked to post the jar file so that GCJ developers can investigate the problem. If the problem is still present, you probably have a class library problem so you should continue on with this tutorial.

  1. The next step is to check out the *same version* the plugin into an eclipse workspace. The SDK has a list of all of the plugins and corresponding cvs tags in a map file on the release page for each released version.

Once you have the plugin, right click on plugin.xml or META-INF/MANIFEST.MF -> PDE Tools -> Create Ant Build File. If you are using a jarred pluigns, right click on the build.xml file that was just generated and go to Run As -> "Ant Build ...". In the dialogue that pops up, select build.update.jar and unselect build.jars. Now click run to start the build.

If you are using a plugin that is not jarred, right click on the generated build.xml file and go to "Run As" -> "Ant Build" to build the jars for the plugin.

Click on the project and hit F5 to see the jar(s) you have just compiled.

Now that the jars have been compiled, you need to move the jar causing the problem from the system and add a symlink from /usr/share/eclipse/plugins to the jar in your workspace. Using the previous example, I would run this set of commands to do this:

sudo mv /usr/share/eclipse/plugins/org.eclipse.update.core_3.2.1.v20092006.jar{,.orig}
sudo ln -s ~/workspace/org.eclipse.update.core/org.eclipse.update.core_3.2.1.200610031527.jar \

Notice that the file name of the jar in the workspace is different from the filename of the jar in /usr/share/eclipse. Make sure that the link name is the same as the jar you moved out of the way.

# Once you have the link in place, it's time to start debugging. The approach I usually take is to narrow down the problem code by adding print statements at the appropriate places and comparing the output of Eclipse using GCJ and Sun's VM. You will most likely have to rebuild your plugin many times. Before you attempt to rebuild, you have to delete the @dot directory and the jar itself. If you don't do this, you will not get a new jar with your changes.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.