Unable to Acquire the State Change Lock

java osgi eclipse-luna
Steffi S. picture Steffi S. · Feb 20, 2015 · Viewed 18.6k times · Source

Our products are using the latest production-ready release of SWT, 3.7.2. Now since no one back then knew what the next Java version would be called (and how would they know that 8 came after 7, that's like higher mathematics), we were forced to swap the org.eclipse.osgi from 3.7.2 to 3.10.0, so that we can now support Java 8. While that's maybe not the best of ideas, in theory it should work.

Of course, being the major screw-up that Eclipse Luna is, there is this one "error" when we start our applications (about 50 percent of the time, I'd guess):

org.osgi.framework.BundleException: Unable to acquire the state change lock for the module: osgi.identity; osgi.identity="org.eclipse.osgi"; type="osgi.bundle"; version:Version="3.10.0.v20140606-1445"; singleton:="true" [id=0] STARTED [STARTED] invalid
at org.eclipse.osgi.container.Module.lockStateChange(Module.java:329)
at org.eclipse.osgi.container.SystemModule.init(SystemModule.java:44)
at org.eclipse.osgi.container.SystemModule.start(SystemModule.java:170)
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:393)
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:412)
at org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.startBundles(ConfigApplier.java:307)
at org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.install(ConfigApplier.java:108)
at org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:129)
at org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:143)
at org.eclipse.equinox.internal.simpleconfigurator.Activator.start(Activator.java:48)
at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:771)
at org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:764)
at org.eclipse.osgi.internal.framework.BundleContextImpl.start(BundleContextImpl.java:721)
at org.eclipse.osgi.internal.framework.EquinoxBundle.startWorker0(EquinoxBundle.java:936)
at org.eclipse.osgi.internal.framework.EquinoxBundle$EquinoxModule.startWorker(EquinoxBundle.java:319)
at org.eclipse.osgi.container.Module.doStart(Module.java:571)
at org.eclipse.osgi.container.Module.start(Module.java:439)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1562)
at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)
at org.eclipse.osgi.container.SystemModule.startWorker(SystemModule.java:242)
at org.eclipse.osgi.container.Module.doStart(Module.java:571)
at org.eclipse.osgi.container.Module.start(Module.java:439)
at org.eclipse.osgi.container.SystemModule.start(SystemModule.java:172)
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:393)
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:412)
at org.eclipse.osgi.launch.Equinox.start(Equinox.java:115)
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:320)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:232)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
at org.eclipse.equinox.launcher.Main.main(Main.java:1386)

There's not much information on the web what the problem is, most suggest to just delete the workspace, but for most it only happens when starting up Eclipse, not the final applications - nonetheless, I deleted workspaces and the runtime-folders. Nothing helps. The "error" gets thrown in the exported product as well, but as far as I can tell, everything still works as expected.

Is there a way to fix it? And if not, is there a way to just hide that stupid exception (disable logging for a moment, clearing the log, whatever, I'm not picky)?

Answer

Prashant Gadekar picture Prashant Gadekar · Apr 16, 2017

I solved problem by following these simple steps,

  1. Go to your eclipse directory and open configuration directory.
  2. open org.eclipse.osgi directory.
  3. open .manager folder.
  4. Delete .fileTableLock file.
  5. Restart your eclipse.

Related questions

A cycle was detected in the build path of project xxx - Build Path Problem

I'm in the process of converting my projects to OSGI bundles using maven and eclipse. Maven builds the stuff just fine, only I get the above error now within Eclipse. How can I find out which project causes this? Is …

Read More
Reading my own Jar's Manifest

I need to read the Manifest file, which delivered my class, but when I use: getClass().getClassLoader().getResources(...) I get the MANIFEST from the first .jar loaded into the Java Runtime. My app will be running from an applet or …

Read More
What does OSGi solve?

I've read on Wikipedia and other sites about OSGi, but I don't really see the big picture. It says that it's a component-based platform, and that you can reload modules at runtime. Also the "practical example" given everywhere is the …

Read More