Community
Participate
Working Groups
Build Identifier: 20100917-0705 The same problem has Eclipse 3.6.1, STS 3.5.2 (201101081000). Eclipse 3.5 and STS 2.3.3M2 open the workspace without problems. There are many projects in the workspace; smaller workspaces can be opened without problems. Workspace cannot be opened even with the clean Eclipse so I don't think that there is a problem with some additional plugin. After opening I can use menu and some windows, but I cannot f.e write any character into editor, or expand a working set in the package explorer - after that Eclipse does not respond any more. The same problem is with 64bit Eclipse on another machine and the same workspace. ---- Partial workaround from http://www.tooltwist.com/forums/viewtopic.php?id=72: # cd .metadata/.plugins # mv org.eclipse.core.resources org.eclipse.core.resources.safe Start eclipse, it should start okay, but may be missing project information - just shut it down. # rm -rf org.eclipse.core.resources # mv org.eclipse.core.resources.safe org.eclipse.core.resources Reproducible: Sometimes Steps to Reproduce: 1. Huge project with many files, compiled from the command line behind the back of the Eclipse. 2. "./eclipse -clean -refresh -debug -data ~/work/workspaces/my" or simply run Eclipse with the default settings and open this workspace 3. The final cut is to press the spacebar in some editor or expand some project in explorer.
Created attachment 187428 [details] Log from the commandline ./eclipse -clean -refresh -debug -data ~/work/workspaces/my and eclipse.ini - see another attachement.
Created attachment 187431 [details] CPU Snapshot Created with VisualVM 1.3.
Created attachment 187432 [details] Memory snapshot Created with VisualVM 1.3.
Created attachment 187433 [details] Thread dump Created with VisualVM 1.3.
Created attachment 187434 [details] Eclipse configuration file
From the stack dump it doesn't appear deadlocked. Everything is blocked on Worker-0. However this thread doesn't appear to be blocked by anything and is presumably still running fine. By "hang" do you mean it locks up forever, or just for a longer time than you expect? Is the CPU usage low or high during this period? "Worker-0" prio=10 tid=0x097a2400 nid=0x75b0 runnable [0x7d3fd000] java.lang.Thread.State: RUNNABLE at org.eclipse.core.internal.jobs.DeadlockDetector.resizeGraph(DeadlockDetector.java:630) at org.eclipse.core.internal.jobs.DeadlockDetector.lockAcquired(DeadlockDetector.java:290) at org.eclipse.core.internal.jobs.LockManager.addLockThread(LockManager.java:141) - locked <0xa2d0c040> (a org.eclipse.core.internal.jobs.DeadlockDetector) at org.eclipse.core.internal.jobs.OrderedLock.setCurrentOperationThread(OrderedLock.java:269) at org.eclipse.core.internal.jobs.OrderedLock.attempt(OrderedLock.java:129) - locked <0xa23cad00> (a org.eclipse.core.internal.jobs.OrderedLock) at org.eclipse.core.internal.jobs.OrderedLock.createSemaphore(OrderedLock.java:148) - locked <0xa23cad00> (a org.eclipse.core.internal.jobs.OrderedLock) at org.eclipse.core.internal.jobs.OrderedLock.acquire(OrderedLock.java:105) at org.eclipse.wst.common.componentcore.internal.builder.DependencyGraphImpl.waitForAllUpdates(DependencyGraphImpl.java:667)
Sorry, the workaround does not help any more (it did some months ago ...?!). But I have found another one - I have turned off the Refreshing Workspace On Startup (and also unchecked all plugin activations on startup, except AnyEdit Tools and Automatic Updates Scheduler). It can be done because Eclipse works until I try to work with some project source file; so it saves preferences ... and hangs after I try to close Eclipse.
John, yes I mean it runs forever. Normally it refreshes the workspace around 5 minutes, not more, and I can edit files. But when it hangs, it takes one processor core to 100% and runs - to longest run I have tried was about 3 hours. Without change, it had to be killed. And there are no cyclic dependencies between projects.
This is actually a deadlock on WST. It appears as a busy loop because DependencyGraphImpl#waitForAllUpdates spins in a busy wait loop which is why we see the lock management code in this stack. Worker-0 is really waiting for the GraphUpdateJob to finish (in worker-4). GraphUpdateJob is waiting for the lock held by Worker-0. "Worker-4" prio=10 tid=0x0970cc00 nid=0x75d9 in Object.wait() [0x79c6b000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xa0914798> (a org.eclipse.core.internal.jobs.Semaphore) at org.eclipse.core.internal.jobs.Semaphore.acquire(Semaphore.java:39) - locked <0xa0914798> (a org.eclipse.core.internal.jobs.Semaphore) at org.eclipse.core.internal.jobs.OrderedLock.doAcquire(OrderedLock.java:176) at org.eclipse.core.internal.jobs.OrderedLock.acquire(OrderedLock.java:110) at org.eclipse.core.internal.jobs.OrderedLock.acquire(OrderedLock.java:84) at org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.java:118) at org.eclipse.core.internal.resources.Workspace.prepareOperation(Workspace.java:1914) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1970) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:793) at org.eclipse.jdt.core.JavaCore.setClasspathVariables(JavaCore.java:4930) at org.eclipse.jdt.core.JavaCore.setClasspathVariable(JavaCore.java:4893) at org.maven.ide.eclipse.jdt.BuildPathManager.setupVariables(BuildPathManager.java:680) at org.maven.ide.eclipse.jdt.internal.MavenClasspathVariableInitializer.initialize(MavenClasspathVariableInitializer.java:26) at org.eclipse.jdt.core.JavaCore.getClasspathVariable(JavaCore.java:2828) at org.eclipse.jst.j2ee.internal.project.J2EEProjectUtilities.getResolvedPathForArchiveComponent(J2EEProjectUtilities.java:905) at org.eclipse.jst.j2ee.internal.common.VirtualArchiveComponentAdapterFactory.getAdapter(VirtualArchiveComponentAdapterFactory.java:23) at org.eclipse.core.internal.runtime.AdapterManager.getAdapter(AdapterManager.java:295) at org.eclipse.wst.common.componentcore.internal.resources.VirtualArchiveComponent.getAdapter(VirtualArchiveComponent.java:227) at org.eclipse.wst.common.componentcore.internal.resources.VirtualArchiveComponent.getUnderlyingDiskFile(VirtualArchiveComponent.java:282) at org.eclipse.wst.common.componentcore.internal.resources.VirtualArchiveComponent.getAdapter(VirtualArchiveComponent.java:215) at org.eclipse.wst.common.componentcore.internal.resources.VirtualArchiveComponent.exists(VirtualArchiveComponent.java:194) at org.eclipse.wst.common.componentcore.internal.resources.VirtualComponent.getRawReferences(VirtualComponent.java:401) at org.eclipse.wst.common.componentcore.internal.builder.DependencyGraphImpl$GraphUpdateJob$1.run(DependencyGraphImpl.java:463) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.wst.common.componentcore.internal.builder.DependencyGraphImpl$GraphUpdateJob.run(DependencyGraphImpl.java:422) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
This was fixed for Helios SR2. There is also a hot fix posted to that bug, if you just want to try that. (Although upgrading to Helios SR2 is recommended.) *** This bug has been marked as a duplicate of bug 327801 ***
