Debugging Eclipse Application Problem: Launches repeatedly

Question

I'm having a problem debugging an Eclipse Application from Eclipse. When I launch the Debug Configuration, the Eclipse Application starts up and then stops repeatedly. It shows the splash screen and then disappears. This is the farthest it gets before restarting:

MyDebugConfiguration [Eclipse Application]  
    org.eclipse.equinox.launcher.Main at localhost:2599 
     Thread [main] (Running) 
     Daemon Thread [Signal Dispatcher] (Running) 
     Daemon Thread [State Data Manager] (Running) 
     Daemon Thread [Framework Event Dispatcher] (Running) 
     Thread [State Saver] (Running) 
     Daemon Thread [Start Level Event Dispatcher] (Running) 
     Thread [Refresh Packages] (Running) 
    C:\MyApp\eclipse\jdk\jre\bin\javaw.exe (Sep 18, 2008 9:38:19 AM)

I am using Version 3.4.0 of the Eclipse SDK.

What is causing this?

Answer 1

Have you tried launching Eclipse with the -clean option? This may resolve the issue if it's somehow related to a configuration problem or the registry cache.

Answer 2

Does your eclipse application have an analog to the hidden logfile in the workspace on launch of the IDE? You can find this in workspace/.metadata/.log

If your application has that somewhere, you might be able to get a little bit better information on what's happening at startup of your eclipse app.

Answer 3

I always add the -console and -consoleLog to the launch configuration.

The first will dump the eclipse log to the console, and the second gives you access to the OSGi console.

In this situation, I check the status of all bundles (using ss). Chances are that the bundle you are interested in hasn't been started. This is probably due to:

• an exception in the Activator.
• an unresolved dependency of the bundle.

If you haven't already seen the error via the consoleLog, then you try and start the bundle manually on the console, with start <bundle-number>. The <bundle-number> is the index of the bundle as seen in ss output. If it is a problem starting the bundle, then the stack trace will be useful in tracking down the real problem.