Community
Participate
Working Groups
Build ID: I20080617-2000 Steps To Reproduce: 1. Install eclipse (eclipse-jee-ganymede-win32.zip). 2. Start eclipse. 3. Select multiple projects from the CVS Repository view. 4. Check out the selected projects. After a while, eclipse hangs within the check out operation. The check out operation cannot be canceled in the Progress view and if Eclipse is closed an dialog is shown with the message "The user operation is waiting for background work to complete".
Created attachment 109887 [details] Check out result after a few minutes
Created attachment 109888 [details] Thread dump
(In reply to comment #0) > After a while, eclipse hangs within the check out operation. The check out > operation cannot be canceled in the Progress view and if Eclipse is closed an > dialog is shown with the message "The user operation is waiting for background > work to complete". By "eclipse hangs" you meant it got unresponsive or the fact that the checkout operation blocked whole workspace? Was the checkout operation still in progress at the time you made the screen shot? Checking out a huge project (or plenty of them) can take "a while". I think we can both agree on this. The problem here is the completely workspace, isn't?
At the time the screenshot was taken, eclipse has no harddisk and CPU activity. The dialog "Checking out.." does not close automatically. Pressing "Cancel" closes the dialog. Next, an attempt to checkout a single project results in "The user operation is waiting for background work to complete.".
Continued: If eclipse is closed a dialog is displayed "The user operation is waiting for background work to complete." with a disabled cancel button. The eclipse process must be killed using the task manager.
I have a similar eclipse hang (workspace locked) when I try to close a Java project and open another Java Project. Eclipse starts to build the workspace and the job never completes. It's stuck for more than few hours on 0%. Cancelling the operation doesn't do anything.
The lock in Worker-28 is causing the deadlock. Please look at the John' suggestion in bug 245573, comment 12.
Chuck, Could you take a look at this? Looks like a problem with module core model locking.
Bug 236438 not only improves performance, it will keep the second attempt (on Worker-28) from trying to load the already loading EMF Edit model, and thus should prevent this deadlock from occurring. *** This bug has been marked as a duplicate of bug 236438 ***
Not solved, still the same behaviour - impossible to use Eclipse 3.4.
Joachim, bug 236438 was fixed in WTP 3.0.1. WTP version numbers are not the same as Eclipse version numbers. Are you using WTP 3.0.1 or newer? This would mean using Eclipse 3.4.1, or Ganymede SR1.
I used Eclipse 3.4.1, but the third retry today works without any problems. I will retry more times.
Created attachment 114402 [details] Thread dump from Eclipse 3.4.1 Hang also occurs in the Ganymede SR1
Setting the found in version to 3.0.2 since the last comment says it happens in Ganymede SR1
Moving this over to jsdt... seems all the locked threads are due to org.eclipse.wst.jsdt.internal.ui.viewsupport.ProblemMarkerManager$1.run(ProblemMarkerManager.java:173)
Is it possible that com.csc.dip.projectset.ui.ProjectSetUI gets a workspace lock, which in turn blocks org.eclipse.jdt.core.JavaCore.setClasspathContainer which is also trying to get a workspace lock?
I think the deadlock is being caused by both org.eclipse.jdt.core.JavaCore.setClasspathContainer and com.csc.dip.projectset.ui.ProjectSetUI trying to get the workspace lock on the same thread. Even though JSDT is on the stack a number of times, it has no locks.
Phil, why are you saying that org.eclipse.jdt.core.JavaCore.setClasspathContainer takes the workspace lock? In fact, it only runs in an IProject scheduling rule. Also how did you find out that ProjectSetUI takes a workspace lock? Do you have the source for this? John, again I'm not able to debug this deadlock as all looks right from the calls to Platform/Resources. Would you have any idea of what's causing the deadlock?
I can't see a problem from this new stack trace. I will note that this new stack trace is completely unrelated to the original stack trace, which was a clear deadlock in WTP code that was fixed. Also the steps are obviously not as simple as comment #0 since there is commercial (non-Eclipse) code running here. The only possibility that comes to mind is another case of bug 246136, where someone is creating their own scheduling rule that doesn't follow the scheduling rule contract.
Thanks John.
Joachim, there is not much we can do here since another component (com.csc.dip.projectset.ui) is involved and we don't have the source for it. You should report the problem to the provider of com.csc.dip.projectset.ui. Closing as NOT_ECLIPSE. Please reopen if you have evidence that the bug is in Eclipse.
Thanks for your efforts.
Verified for 3.5M4
