Community
Participate
Working Groups
Hello All, I just installed Europa version of "Eclipse IDE for Java EE Developers" for linux. After the initial start of eclipse and configured the workspace I was not able to start eclipse again after exiting the first instance. I received a message "Workspace in use or cannot be created, choose a different one". On examination of the workspace, I noticed that the '.lock' file was not removed. I think this is the cause for the above error message. Once '.lock' is removed manually, I was able to start eclipse again. On closer examination of the log file at '<myhomedir>/workspace/.metadata/.log', I discovered the following error message. Is this a bug in eclipse? Note: The same .lock file is also not removed on a WindowsXP machine. But it seems Eclipse is not affected by it and continues to load properly. !SESSION 2007-07-19 10:07:03.172 ----------------------------------------------- eclipse.buildId=I20070625-1500 java.version=1.5.0_12 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US Command-line arguments: -os linux -ws gtk -arch x86 !ENTRY org.eclipse.osgi 2 0 2007-07-19 10:07:26.452 !MESSAGE While loading class "org.eclipse.mylyn.internal.context.ui.actions.ContextMenuContributor", thread "Thread[Worker-0,5,main]" timed out waiting (5000ms) for thread "Thread[Worker-2,5,main]" to finish starting bundle "update@plugins/org.eclipse.mylyn.context.ui_2.0.0.v20070627-1400.jar [253]". To avoid deadlock, thread "Thread[Worker-0,5,main]" is proceeding but "org.eclipse.mylyn.internal.context.ui.actions.ContextMenuContributor" may not be fully initialized. !STACK 0 org.osgi.framework.BundleException: State change in progress for bundle "update@plugins/org.eclipse.mylyn.context.ui_2.0.0.v20070627-1400.jar" by thread "Worker-2". at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1141) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:258) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:408) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:369) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:357) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.eclipse.osgi.framework.internal.core.BundleLoader.loadClass(BundleLoader.java:289) at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:227) at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1269) at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:160) at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:788) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243) at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:51) at org.eclipse.mylyn.internal.tasks.ui.util.TasksUiExtensionReader.readDynamicPopupContributor(TasksUiExtensionReader.java:376) at org.eclipse.mylyn.internal.tasks.ui.util.TasksUiExtensionReader.initStartupExtensions(TasksUiExtensionReader.java:146) at org.eclipse.mylyn.tasks.ui.TasksUiPlugin.start(TasksUiPlugin.java:333) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.core.internal.runtime.InternalPlatform.start(InternalPlatform.java:877) at org.eclipse.core.internal.plugins.PluginDescriptor.doPluginActivation(PluginDescriptor.java:360) at org.eclipse.core.internal.plugins.PluginDescriptor.getPlugin(PluginDescriptor.java:340) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.ui.internal.EarlyStartupRunnable.getPluginForCompatibility(EarlyStartupRunnable.java:149) at org.eclipse.ui.internal.EarlyStartupRunnable.run(EarlyStartupRunnable.java:73) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.Workbench$54.run(Workbench.java:2190) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Caused by: org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException ... 40 more Root exception: org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1141) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:258) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:408) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:369) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:357) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.eclipse.osgi.framework.internal.core.BundleLoader.loadClass(BundleLoader.java:289) at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:227) at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1269) at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:160) at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:788) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243) at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:51) at org.eclipse.mylyn.internal.tasks.ui.util.TasksUiExtensionReader.readDynamicPopupContributor(TasksUiExtensionReader.java:376) at org.eclipse.mylyn.internal.tasks.ui.util.TasksUiExtensionReader.initStartupExtensions(TasksUiExtensionReader.java:146) at org.eclipse.mylyn.tasks.ui.TasksUiPlugin.start(TasksUiPlugin.java:333) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.core.internal.runtime.InternalPlatform.start(InternalPlatform.java:877) at org.eclipse.core.internal.plugins.PluginDescriptor.doPluginActivation(PluginDescriptor.java:360) at org.eclipse.core.internal.plugins.PluginDescriptor.getPlugin(PluginDescriptor.java:340) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.ui.internal.EarlyStartupRunnable.getPluginForCompatibility(EarlyStartupRunnable.java:149) at org.eclipse.ui.internal.EarlyStartupRunnable.run(EarlyStartupRunnable.java:73) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.ui.internal.Workbench$54.run(Workbench.java:2190) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) cher.Main.run(Main.java:1169)
How is it shutting down after the first time? The .lock is created when Eclipse starts up, and then normally removed when Eclipse shuts down. It sounds like the shutdown isn't normal. Did it crash whilst launching, or was it closed with (say) kill -9? Also note there's an issue with Europa and GTK's printing libraries which might be an issue (http://www.eclipsezone.com/eclipse/forums/t99035.rhtml) if you're killing the process. On a Windows system, Eclipse shouldn't continue to launch if the .lock file is present. Are you sharing a filesystem between the two, or are they on different disks?
The .lock file is not deleted upon close when using the default java.nio locking. Instead each instance of eclispe tries to perform file channel locking on the file if it exists. Something else must be going on. Can you verify that the eclipse process has ended when you exit? The other error in your log "State change in progress for bundle" is a duplicate of bug 188524.
On WindowsXP with SP2: ====================== Eclipse 3.3 starts up whether '.lock' file is present or not. There is a '.log' file generated with exceptions messages when Eclipse is exited. I am running Eclipse from a local harddrive that is not shared and the workspace is also located on the same harddrive and not shared. On a OpenSUSE 10.2 Linux system: =========================== Once Eclipse is started and exited via the GUI, the Eclipse process is still present. I would have to manually kill the process. If I were to start Eclipse again, I would get a dialogbox showing "Workspace in use or cannot be created, choose a different one". I believe this is due to the '.lock' file not being removed by Eclipse. Subsequently, if I want to start Eclipse again, I must manually remove the residual '.lock' file before eclipse can successfully start.
i am working on centos 4 (rhel 4) am i am experiencing the same problem, with the same solution as mentioned in the previous comment. i have started/stopped the tool many times, check the process table to see if there were any lingering processes that were obviously eclipse related (there were none). it appears as the tool is exitting properly, just not removing the lock file. i have to remove the .lock file manually to restart the tool. if i wanted to promote this tool to my group, i would have to write a wrapper script just to delete the .lock file. ktomasek [28]>uname -a Linux d2al220 2.6.9-34.0.2.ELsmp #1 SMP Fri Jul 7 18:22:55 CDT 2006 x86_64 x86_64 x86_64 GNU/Linux Version: 3.1.2 Build id: M20060118-1600
(In reply to comment #4) > Version: 3.1.2 > Build id: M20060118-1600 > Could you try a 3.3 version of Eclipse. In 3.1 the eclipse launcher will spawn a separate java process. The java process is what locks the .lock file. Did you make sure there are no java process left over when the issue occurs?
Just as a confirmation. I'm currently using "Eclipse IDE for Java EE Developers" v3.3.1.1 and I no longer experience the problem stated in this bug report.
I can confirm the same bug on Ubuntu 7.10 (Linux 2.6.22) using Eclipse 3.3.1. I've been killing the process to get things working again. I can also confirm it is not a problem with Eclipse 3.2.
As an addition to comment#6 of this report. I'm currently using OpenSuse 10.3 and using Eclipse version 3.3.1.1. After running and closing the eclipse application, the ".lock" file remains present but does not cause any issues when running eclipse in subsequent startups. Now, I do not know if this file is supposed to be removed after the last instance of eclipse is exited.
Further to my comments in comment #7, The lock file issue is a red herring. If you run Eclipse as root there is no problem. Read on for the full story. If you run Eclipse as a normal user, quit Eclipse and then delete the .lock, go and check if the eclipse process has been ended. In my experience it is not. If you delete the .lock file you will be able to restart Eclipse and not be prompted to choose a different workspace, but checking gnome-system-monitor or Top will reveal that a 2nd Eclipse process has been started and this one will also not end when you exit Eclipse. I have tested this with the following Eclipse versions and observed the same results each time. eclipse-java-europa-fall2-linux-gtk eclipse-rcp-java-europa-fall2-linux-gtk eclipse-SDK-3.3-linux-gtk eclipse-SDK-3.3.1.1-linux-gtk In my previous comment #7 I mentioned that I did not have this problem with Eclipse 3.2. This version was installed from the Ubuntu repository and appears to have been set up to run as root. When eclipse-SDK-3.3.1.1-linux-gtk is run as root, there is no problem. The Eclipse process is terminated properly when exiting Eclipse (if you want to check this run qnome-system-monitor or top as root). The strange thing is, when run as root, a workspace/.metadata folder is created in roots directory, but no .lock file. This seems to solve this problem, but it raises a concern in my mind about running Eclipse as root (I'm using gksudo in a menu item). Why does it need root authority? I don't like this, especially since Eclipse could be exposed to the Intenet in a Team environment or if your using some of the features in MyEclipse.
As a reply to Comment#9, I failed to mention how I had my Eclipse 3.3.1.1 setup in my OpenSuse 10.3. I did not use the eclipse from the OpenSuse 10.3 repos as it was not the latest. I logged in as root, downloaded the tar.gz file from eclipse.org and uncompressed it into /usr/local/bin/eclipse and did a chown to owner=root and group=root and chmod /usr/local/bin/eclipse to 0x755. I then log into the system as a non-root user and executed the program /usr/local/bin/eclipse/eclipse. Hope this helps.
Comment#10 ...part2 To continue... After logging in as a non-root user and running /usr/local/bin/eclipse/eclipse the first time, the workspace directory will be created in my non-root user's home directory. As a correction. When a chmod was performed on the /usr/local/bin/eclipse directory, it should be noted that a chown for owner=root and group=root was performed on /usr/local/bin/eclipse and it's subdirectory as well. It was not necessary to do a chmod 0x755 for the whole directory and subdirectory.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
