Community
Participate
Working Groups
Created attachment 233477 [details] My Eclipse Configuration Greetings everyone, I'm having two problems with Working Sets which have been happening for sometime, I think since the Indigo release. I'm running right now the latest Kepler, with PDT 3.2 and when I close Eclipse and shutdown the computer my working sets are "lost". All of the projects go to the "Other Projects" set, and I have to Edit the working set again to remark them as part of it. This does not happen everytime though, sometimes what happens is that some of the closed projects on an working set will move to the Other Projects, and it seems kind of random. Another thing to note is that, when I go to edit the project, the moved projects have a dashed checkmark instead of a full line. How to reproduce ---------------- Have a lot of projects (I have around 30). Organize them in working sets (I have 6 currently) Close eclipse Shutdown computer Restart Expected behavior ----------------- Projects are still under their Working Sets and they keep their closed\open status Real behavior ------------- Some or all of the projects are moved to the Other Projects set
I've seen this few times too. At least for me, this happens extremely infrequently, maybe once every few weeks if not months. Logs are completely clean when this happens.
So, some additional information about this bug, as it happens for me every time. I'm now running on . I did a fresh install Version: Kepler Service Release 1 Build id: 20130919-0819 As plugins I have, eGit, JS Dev, PHP CS, PDT, Subversion, LUA Dev. This is happening on my PHP workspace. When I close eclipse, or turn off the computer, when I restart eclipse, the following happens: - All of my OPEN projects will be closed; - These projects will be moved from their Working Set to the "Other Projects" - The projects that were closed before, will stay where they are. This has been consistent for me. Also, when I go to edit a working set. All the CLOSED projects on it, when I click save will be moved to the "Other Projects" set.
I am not sure this is the only scenario that leads to "lost" working sets, but I have steps to reproduce the problem with java working sets and I think the same can happen with any IWorkingSetUpdater. Using fresh eclipse sdk 4.4m3 and clean workspace * create java projects A, B * add project A to java working set A * add projects B to java working set B * shutdown workbench * delete project A from filesystem (this can happen as a result of out-of-workspace update from scm action like git-pull for example) * start workbench (1) * close and restart workbench again At this point working set B is lost (1) is the interesting part, here is what happens internally WorkingSetManager restoreWorkingSetState iterates over all working sets that existed at shutdown and among other things invokes IWorkingSetUpdater#add. Note that not all working sets are fully loaded and registered with WorkingSetManager at this point. In case of java working set, JavaWorkingSetUpdater#add will validate working set members and call IWorkingSet#setElements if any change is detected. This triggers WorkingSetManager.saveWorkingSetState, which writes incomplete workingsets.xml to disk. Even though WorkingSetManager in-memory state still contains all working sets, it will be lost unless something triggers WorkingSetManager.saveWorkingSetState before shutdown. ==== The easiest fix for this particular problem is probably defer WorkingSetManager.saveWorkingSetState during WorkingSetManager.restoreState.
Created attachment 237289 [details] proposed patch
(In reply to Igor Fedorenko from comment #3) > I am not sure this is the only scenario that leads to "lost" working sets, > but I have steps to reproduce the problem with java working sets and I think > the same can happen with any IWorkingSetUpdater. > > Using fresh eclipse sdk 4.4m3 and clean workspace > * create java projects A, B > * add project A to java working set A > * add projects B to java working set B > * shutdown workbench > * delete project A from filesystem (this can happen as a result of > out-of-workspace update from scm action like git-pull for example) > * start workbench (1) > * close and restart workbench again > > At this point working set B is lost > It works fine with the '-clearPersistedState' CLI option so it is somehow connected to the E4 model. I'll continue investigation of the issue, Daniel
I find it odd that you can't reproduce the problem given detailed steps to reproduce and the attached patch, which should at least highlight the problem. At any rate, I've changed m2e not to use java working sets any more, so my users are not affected by this problem.
(In reply to Igor Fedorenko from comment #6) > I find it odd that you can't reproduce the problem given detailed steps to > reproduce and the attached patch, which should at least highlight the > problem. At any rate, I've changed m2e not to use java working sets any > more, so my users are not affected by this problem. Thanks for update. I was able to reproduce the issue. The 'clearPersistedState' clue mentioned in my previous comment is the another issue that actually hides the considered one. After fixing it I'm able to reproduce the primary issue with and without the 'clearPersistedState' option. I will continue my investigation, Daniel
I've pushed the proposal of the patch to Gerrit: https://git.eclipse.org/r/#/c/22232/ thanks, Daniel
(In reply to Daniel Rolka from comment #8) > I've pushed the proposal of the patch to Gerrit: > https://git.eclipse.org/r/#/c/22232/ Released as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=caa114ecd0ea2afc36dfba4a63196da09244d144 Please retest. PW
Daniel, please verify the fix and close this bug if it's fixed.
Verified in the build: I20140225-0800 Daniel
This change led to bug 493335 when dealing with multiple windows.
