Community
Participate
Working Groups
Build Identifier: M20100211-1343 On occasion, when using TPTP, and when moving/renaming packages and projects via refactoring, the affected workspace gets corrupted -- eclipse fails to start, usually stalling with the message "initializing JDT tooling". Other workspaces are not affected. My first suspicions would be polarion/SVN (which has ALWAYS been flaky regarding refactoring), but the problem has occurred most often when using TPTP, when releasing TPTP resources (I forget the exact terminology). To date, the only solution is to delete the workspace in the file system, and then rebuild the workspace from scratch, from the repository -- not a pleasant solution, especially since I have now done it almost once a week. I have tried half measures, of deleting bits and pieces of the metadata and project files in the workspace, but to no avail. It seems to be all or nothing, or you end up with a lobotomized workspace that SVN goes bonkers over. (BTW: I can't begin to tell you how truly bad SVN support in Eclipse continues to be. I've given up long ago submitting bugs). Reproducible: Sometimes
(In reply to comment #0) > eclipse fails to > start, usually stalling with the message "initializing JDT tooling". There's been several of these bugs reported over the past year or so. If you query bugzilla you should hit a few of these. What kind of Java development are you doing anyway? Regular Java applications? Servlets and Tomcat-ish stuff? OSGi bundles/Eclipse plug-ins? (In reply to comment #0) > (BTW: I can't begin to tell you how truly bad SVN support in Eclipse continues > to be. I've given up long ago submitting bugs). Well I'm moving this bug to the Java tooling team but you'll have to take it up with Subversive for your Subversion concerns...though it seems you've given up on that avenue, sorry to hear that.
This is very likely a deadlock in the container initialization. I would report to TPTP to find out what kind of specific classpath container they are defining.
I forgot to mention this, but if you get into the state where it hangs again, please try to capture a thread dump. Thanks, Jon. http://wiki.eclipse.org/How_to_report_a_deadlock
A thread dump is probably the only way to make progress on this.
(In reply to comment #1) > (In reply to comment #0) > > eclipse fails to > > start, usually stalling with the message "initializing JDT tooling". > > There's been several of these bugs reported over the past year or so. If you > query bugzilla you should hit a few of these. What kind of Java development are > you doing anyway? Regular Java applications? Servlets and Tomcat-ish stuff? > OSGi bundles/Eclipse plug-ins? I'm doing vanilla java development (no plugins, no web stuff, nothing fancy), but with many projects (25). (In reply to comment #2) > This is very likely a deadlock in the container initialization. > I would report to TPTP to find out what kind of specific classpath container > they are defining. No, it most recently happened without TPTP anywhere in sight. Perhaps the corruption from these two cases (one TPTP, the other a crappy refactor due to Subversive) are related, but in an area common to both (resource/file management?).
Created attachment 166685 [details] Thread dump of eclipse while hung "initializing java toolig (1%)"
(In reply to comment #3) > I forgot to mention this, but if you get into the state where it hangs again, > please try to capture a thread dump. Thanks, Jon. > http://wiki.eclipse.org/How_to_report_a_deadlock I saved the corrupt workspace and the problem (as has always been the case) is 100% reproducible. Attached is the thread dump, but the tool couldn't even recognize the hung eclipse as eclipse (I had to find the PID via the task manager), so it may not tell you much.
That sure looks like an interesting stack trace! Quick findings: Thread "Worker-0" and "Worker-5", both related to SVN, both are doing some class loading. Since "Worker-0" is blocked trying to lock a class loader I could imagine that one of the ClassLoader.loadClass() in "Worker-5" is actually holding that look (unfortunately this lock isn't shown in the stack trace). "Worker-5" looks suspecious to me, like its doing too much work during its bundle activator. Perhaps "Worker-5" actually triggered the Job for "Worker-0" , waiting for an answer (see SVNTeamPlugin.getOptionProvider()) in "Worker-0", but "Worker-0" can't complete because it can't obtain a classloader lock. This discovery stuff is pretty new and I wouldn't be surprised if it doesn't prove threadsafe. But maybe its even more complex involving some more threads. Should we ask subversive for comments?
BTW, if classloading is really the issue, there might be a workaround: add this line to configuration/config.ini osgi.classloader.lock=classname which switches the OSGi classloader to more fine grained locking.
Since my last update, when I ran jvisualvm to get the thread dump from the bad workspace, it seems that I somehow subsequently switched an open eclipse window to the bad workspace, and it worked just fine -- a miraculous recovery. Could running jvisualvm have done anything? I'm pretty sure I didn't do anything to the workspace. And, for what it's worth, the previous 3 times I got corrupted workspaces it was TPTP related, and none of those ever recovered, in spite of opening, switching, rebooting, etc. (BTW: Including the workspace name it the window title was an enhancement suggested LONG ago, and as I recall, it was marked as "don't fix". Why is beyond me, but this is something that is sorely needed as developers, such as myself, are becoming more and more workspace-centric.)
OK, bugzilla search was down for a moment (bug 311244), but now that it's back, I see plenty of related bugs, assuming that this is actually one of the many duplicates of bug 291603. Jon, could you verify that you are using a version of subversive that does not contain the fix for bug 291603?
(In reply to comment #10) > (BTW: Including the workspace name it the window title was an enhancement > suggested LONG ago, and as I recall, it was marked as "don't fix". Why is > beyond me, but this is something that is sorely needed as developers, such as > myself, are becoming more and more workspace-centric.) Jon, add -showlocation as an argument to Eclipse via the eclipse.ini file. Here's an example. -showlocation -startup plugins/org.eclipse.equinox.launcher_1.1.0.v20100419.jar --launcher.library plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.0.v20100322-1720 -showsplash org.eclipse.platform --launcher.XXMaxPermSize 256m --launcher.defaultAction openFile -vmargs -Xms40m -Xmx384m In the future, please open separate enhancement requests, bugs, or inquire on the forums so we can keep this particular bug focused on the one issue you are raising. http://www.eclipse.org/forums/
(In reply to comment #11) > OK, bugzilla search was down for a moment (bug 311244), but now that > it's back, I see plenty of related bugs, assuming that this is > actually one of the many duplicates of bug 291603. > > Jon, could you verify that you are using a version of subversive > that does not contain the fix for bug 291603? I am using their latest version which, after checking, is indeed the one mentioned in the bug fix.
Could you please try the same workspace without subversive?
(In reply to comment #14) > Could you please try the same workspace without subversive? As I mentioned above, the corrupted workspace miraculously healed. It no longer hangs, so I can't try anything. Next time it happens I'll try all the things you guys are suggesting (time andpatience alowing).
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. -- The automated Eclipse Genie.
