Skip to main content
Jump to: navigation, search

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.
  2. Next you need to determine where the problem is occurring. A stack trace will give you the clues you need. If the top of the stack trace has no errors within before a plugin, then you'll want to determine if the problem is native compilation of the plugin in question or if there is 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.
  3. The next step is to work with the plugin code. Find the first plugin in the stack trace (i.e. skip over any failures). Next, you want to check out the same version of 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 then PDE Tools -> Create Ant Build File.

    If you are using a jarred plugin, 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:


    Click run to start the build. You will need to click on the project directory and hit F5 to see the jar you have just compiled.

    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. You will need to hit F5 too the jars as well.

  4. 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.

  5. 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. This is necessary because you can't currently debug GCJ-compiled Java code. In the case where you know you have a problem, you are looking to isolate a repeatable scenario that fails. 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.

Back to the top