Community
Participate
Working Groups
I'm getting this deadlock every time I start Eclipse now. All I can do is force-kill it then I restart again and I'm back in the same state. Stack trace attached. Is there even a valid workaround available to me in the meantime? All I've got at the moment is blowing away my workspace :(
Created attachment 223392 [details] Stack trace
Created attachment 223393 [details] Eclipse configuration log
Created attachment 223394 [details] My .factorypath file, if it helps.
Yeah, you've got a lot of moving pieces in there: Scala, ADT, Maven, APT. None of which were probably tested or developed with each other, and all of which probably want to do weird things with the classpath at inopportune moments. Not hard for me to believe that they're not playing by the same rules; hard to know what the fix is. As a workaround to get you unstuck, you might want to try disabling or uninstalling one of those plugins, to see if that'll let you get the app started and get a (partial) build.
Thanks for having a look and for the advice. Thing is though, this isn't a case of things being slow or me getting value X instead of value Y; it's a deadlock. Deadlocks should never happen regardless of how many plugins and things I have installed. JDT's locks shouldn't be exposed so that it's possible for any external entity to misuse them and create a deadlock. I don't mean to sound ranty but even if other plugins were misusing some Eclipse API, I'd say it's the responsibility of the API provider to ensure that no combination of permissible access can cause itself to enter an erroneous state such as a deadlock. Of course all of this is based on the assumption that JDT/APT has a actual deadlock (esp. on internal locks). It looks like it to me and the stack trace implies it but that's not proof. Is there a way to verify? Also, some background info re external plugins: First: Had ADT. (And m2e although that's part Eclipse train now). Everything was fine. Next: Enabled APT for an ADT project through JDT project settings, problem started. Won't stop. Last: Added scala and aspectj for use in other workspaces. I know it looks like I'm going plugin/classpath crazy but they came later. We can ignore in the context of this issue.
Hey, I agree with both the sentiment and the frustration, but the reality is that Eclipse is a big, old codebase and some stuff probably isn't going to get fixed in the near future. (Unless you want to give it a shot yourself? Volunteers welcome...) In particular, the code around classpath modification has been a notorious source of either data races or deadlocks for as long as I can remember; back around the Eclipse 3.3 timeframe I spent about three months trying to fix just one such deadlock (so believe me, I agree with the frustration). The JDT locks *shouldn't* be exposed that way, but they *are*, and that's a very hard problem to solve after the fact. Plus some plugins dodge the supported APIs and call directly into internals, making it extremely hard to solve problems. I doubt there is anyone currently working on JDT who can spare the time to fix this, and even if they did, it's not clear whether it would be possible without breaking backward compatibility of (poorly designed) old APIs. Hurray for legacy. So I think unless you feel like spending the next 3-4 months of your life as an Eclipse developer - which, if you have that luxury, would be awesome! - the unfortunate fact is that a workaround is the best you're going to do right now. You might be able to work around the problem by creating the generated-src directory by hand if it doesn't exist already; or by hand-editing the .classpath file. Basically, trying to bump the process down a different branch that doesn't have the deadlock.
Wow! I had no idea the JDT codebase was in such an unhappy state; you paint a bleak picture, friend, ha! OK, an assumption I didn't realise I had about Eclipse has been invalidated, my expectations successfully managed. :) Thanks for the details. Y'know, I would love to contribute but I've already spent around 2 months this year on open source -- not how I planned to spent my first year of self-employment, net income $0 so far and all that :S -- so unfortunately that won't be happening. So, your suggestion to create the generated src directory by hand I understand completely and I'll give that a try. Thanks! What exactly did you mean by editing .classpath and bumping the process to a different branch? Do you mean changing the order of the APT <classpathentry> element?
There's a lot of work and not a lot of staff. Many things about JDT are awesome, some are not. APT in particular (where I contributed in the 3.3-3.5 timeframe) is basically unstaffed at this point. I keep trying to find time to do more work on it. It's sort of hit the 80% point where it doesn't cause enough people enough pain for them to throw resources at it. It is both a strength and weakness of Eclipse that it tries very hard not to break old API. Makes it hard to fix certain problems. Yes, I'm thinking that maybe if you hand-edit .classpath to put the items in a different order, then the order of initialization or loading might be different and you might dodge the deadlock.
Hmm yes, I completely understand. We were in a very similar scenario in my last job. It's hard to convince stakeholders to spare the time (money) to fix the 20% let alone the remaining 10%, especially when there so many other projects in the pipeline, money issues, politics, 50 other team also competing for their respective 20%'s, argh! Oh well, it's reality when (finite) money is involved. The workaround: I created the APT directory and moved its classpath entry around as you suggested and things work fine now! Thank you very much. I'm back in love with Eclipse again :D
Good, I'm glad to hear the workaround worked!
Since we do have a work around that works, reducing the severity.
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.
