Community
Participate
Working Groups
Build Identifier: 20110916-0149 This bug is extremely serious when tracking changesets, because it looks like the entire file has been changed. Reproducible: Sometimes Steps to Reproduce: 1. Use attached formatter 2. Sometimes it will replace spaces in file with tabs despite the formatter settings clearly says "Spaces-only". Can be temporarly fixed by going to formatter and chosing tabs-only. Save this. Go back and select spaces-only and Save this. Then it will do the right thing until restart.
Created attachment 205058 [details] Formatter says spaces-only. The format of the code says something else
Created attachment 205059 [details] formatter preferences with spaces-only
I couldnt reproduce this with an isolated test case with build I20110927-0800. It is likely that some specific case causes this to fail since you say it fails "sometimes". Do you know the exact trigger? Does this fail for you if you use an isolated test case?
I unfortunately do not know the extract triggering cause. I usually find that it has entered the wrong-formatting mode when i compare with the latest revision on SVN and find everything changed. What i do know is that once it first entered the wrong-formatting mode it seems to be consistently in the wrong mode until manually changed forth and back or restarted. Is there anything i can do after it enters this mode, to see all of the formatting options is is currently using (so i can see if it just confuses the formatter, or several other options has been changed as well)?
I'm not sure how we can locate the problem here, except that you keep observing until you can find a triggering pattern that causes it to appear. One thing you can check is if your project, shared in an SVN repo, has some project -specific settings. You may have set the "spaces" only policy on the workspace settings, but the project specific settings still have a "tabs" only policy. Project settings override the workspace settings. If nothing works and you still face the problem, you can go to Preferences>java Editor> Save Actions and choose Format edited lines instead of Format all. This will make sure that formatting of files you haven't changed remains preserved. (Do this on project specific settings and not workspace settings).
Comment 4 vaguely reminds me of bug 302850, where in rare cases we observed that options were "lost" during an automated test run. We never identified a cause but the issue hasn't occurred for several months now. Should we insert some debug facility so that Steffen can force a dump of all options as seen by the JavaModelManager when Eclipse gets into the bad state?
Would it be helpful if i use JVisualVM to output a heap dump after Eclipse enters the bad formatting mode.?
I just got a thought: I first noticed this bug when i upgraded Eclipse from Helios to Indigo. The attached formatter.xml is the one i exported from Eclipse to you (rather than using the one i imported into Eclipse). But i can see there is a differente between the formatter i originally imported into Eclipse and the one i exported again, namely that the version is different. Could it be that importing a previous version of the formatter, can trigger some strage behavior. I will now also attach the original formatter i imported into eclipse.
Created attachment 205117 [details] Original formatter (ver11)
(In reply to comment #8) > I just got a thought: I first noticed this bug when i upgraded Eclipse from > Helios to Indigo. I don't think that a change in version no. implies a change in options too. And anyway this won't explain how even after toggling from tabs to spaces, you again run into this problem. Did you check the project-specific settings? Is there any formatter profile there? > Should we insert some debug facility so that Steffen can force a dump > of all options as seen by the JavaModelManager when Eclipse gets into > the bad state? Steffen, you can try this - Create a .options file in the root directory of your eclipse install with these debug settings: Turn on debug tracing for org.eclipse.jdt.core plugin org.eclipse.jdt.core/debug=true Restart you workspace. The debug info will be dumped on the console. Ensure that the console buffer size is large enough. You can attach the console output here when the problem appears.
There is no project-specific formatter. I will try to enable debugging and also create a heap dump next time i see the problem
I got the bug again just now. Firstly i had opened eclipse with our branch workspace and i verified the formatter worked fine. I worked on this for 10 minutes. After this i also needed to open our Trunk workspace, and immediately after starting eclipse i found that the formatter was converting spaces to tabs. This happens on all code and there is no project specific settings. I have made head dump (if you can use it) and will attach debug information right away
Created attachment 205179 [details] Debug from eclipse after problem occured
I will let the corrupt eclipse run for as long as possible, so if you have some debug-ideas you want to test, just let me know!
Each time i run my Trunk workspace it now starts in the bad stats. Sounds more and more like a caching problem.
I just checked some more formatter options. Seems like it completly disregards the user specified formatter and use default.
Created attachment 205196 [details] try catch options is also ignored
I found that the bug could always be reproduced if i copied the .metadata folder from one workspace to another. So i created two identical workspaces and fixed the formatter problem for one of the workspaces. Then i made a diff file of what had changed between the two workspaces. I will upload this file. Then you should at least be able to do a partial fix, where the stale formatting cache is refreshed on startup (or first invocation of formatter)
Created attachment 206403 [details] Difference between broken formatter and fixed formatter
Overview of files that differs: Files workspaceBroken/.metadata/.log and workspaceBroken2/.metadata/.log differ Only in workspaceBroken2/.metadata/.plugins/org.eclipse.core.resources/.history/94: 8037029e1906001116fefdc274898d34 Files workspaceBroken/.metadata/.plugins/org.eclipse.core.resources/.projects/test/.indexes/e4/history.index and workspaceBroken2/.metadata/.plugins/org.eclipse.core.resources/.projects/test/.indexes/e4/history.index differ Files workspaceBroken/.metadata/.plugins/org.eclipse.core.resources/.projects/test/org.eclipse.jdt.core/state.dat and workspaceBroken2/.metadata/.plugins/org.eclipse.core.resources/.projects/test/org.eclipse.jdt.core/state.dat differ Only in workspaceBroken/.metadata/.plugins/org.eclipse.core.resources/.root: 16.tree Only in workspaceBroken2/.metadata/.plugins/org.eclipse.core.resources/.root: 17.tree Files workspaceBroken/.metadata/.plugins/org.eclipse.core.resources/.safetable/org.eclipse.core.resources and workspaceBroken2/.metadata/.plugins/org.eclipse.core.resources/.safetable/org.eclipse.core.resources differ Files workspaceBroken/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.core.prefs and workspaceBroken2/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.core.prefs differ Files workspaceBroken/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.ui.prefs and workspaceBroken2/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.ui.prefs differ Files workspaceBroken/.metadata/.plugins/org.eclipse.jdt.core/externalLibsTimeStamps and workspaceBroken2/.metadata/.plugins/org.eclipse.jdt.core/externalLibsTimeStamps differ Files workspaceBroken/.metadata/.plugins/org.eclipse.jdt.core/nonChainingJarsCache and workspaceBroken2/.metadata/.plugins/org.eclipse.jdt.core/nonChainingJarsCache differ Files workspaceBroken/.metadata/.plugins/org.eclipse.jdt.core/savedIndexNames.txt and workspaceBroken2/.metadata/.plugins/org.eclipse.jdt.core/savedIndexNames.txt differ Files workspaceBroken/.metadata/.plugins/org.eclipse.jdt.ui/dialog_settings.xml and workspaceBroken2/.metadata/.plugins/org.eclipse.jdt.ui/dialog_settings.xml differ Files workspaceBroken/.metadata/.plugins/org.eclipse.m2e.logback.configuration/0.log and workspaceBroken2/.metadata/.plugins/org.eclipse.m2e.logback.configuration/0.log differ Files workspaceBroken/.metadata/.plugins/org.eclipse.ui.workbench/workbench.xml and workspaceBroken2/.metadata/.plugins/org.eclipse.ui.workbench/workbench.xml differ
Satyam, do you think this has anything to do with causes mentioned in bug 302850?
I have not seen the behavior again since my last report. It seems most likely that the bad behavior started when upgrading Eclipse and i saw it several time because i use multiple computers each with multiple eclipse workspaces. The problem would then be that eclipse caches the formatter options and after an upgrade the cache is somehow not right anymore. If this is the case, a validation of settings versus cache on startup could be a good idea. I have a workspace with the corrupted behavior so its no issue to reproduce it anymore.
Steffen, we have out hands full as of now with some formatter improvements, so we don't expect to be able to investigate this soon. Thanks for all the info! Satyam, can you please look at this, time permitting? Thanks!
(In reply to comment #22) > I have a workspace with the corrupted behavior so its no issue to reproduce it > anymore. Steffen, would it be possible to give us the corrupted workspace itself?
Is there some way i can strip all sensitive information from configuration or upload the workspace as non-public available? (In reply to comment #24) > (In reply to comment #22) > > I have a workspace with the corrupted behavior so its no issue to reproduce it > > anymore. > > Steffen, would it be possible to give us the corrupted workspace itself?
(In reply to comment #25) Does this formatting problem also happen in a new project that you can create in the same workspace? If so, you could delete the source code of the other projects. If not, can you delete other source folders in the same project? If the workspace is not big, you could send it to my email address satyam.kandula at in.ibm.com. To reduce the size, you could delete the contents in <workspace>/.metadata/.plugins/org.eclipse.jdt.core
I have isolated the problem to the .metadata folder, so it does not depend on any projects. But i dont know what kind of private data is stored in .metadata folder (ie subclipse svn host + password) I will send the file to your email when i get to my machine with the corrupt workspace. (In reply to comment #26) > (In reply to comment #25) > Does this formatting problem also happen in a new project that you can create > in the same workspace? If so, you could delete the source code of the other > projects. > If not, can you delete other source folders in the same project? > > If the workspace is not big, you could send it to my email address > satyam.kandula at in.ibm.com. To reduce the size, you could delete the contents > in <workspace>/.metadata/.plugins/org.eclipse.jdt.core
Steffen, Thanks for the workspace. I am able to see that the JDT/UI preferences has the details of the new formatting profile, but it hasn't trickled down to the JDT/Core preferences which does the real formatting. Investigating more.
Looking at the code and this ended up behaviour, concurrent modification of the JDT/Core options is the only explanation that I have. Problem: Newly imported formatter profile is active in the JDT/UI options, but JDT/Core options/preferences doesn't have the updated formatter settings. Workaround: Change the format profile to some other profile and then reseset back to the required profile should fix the issue. Cause: The API that JDT/Core provides its users to update the options is JavaCore#setOptions(Hashtable). This method sets the complete JDT options to the given hash table. Consumers of this API are expected to call JavaCore#getOptions(), modify the contents and then call JavaCore#setOptions(Hashtable). If a consumer calls JavaCore#getOptions(), and if meanwhile the formatter importer updates the options, before the call to JavaCore#setOptions() an user is likely to run into this problem. May be in this case you would have imported the formatter settings before all the plugins have finished their initialization. I don't know which plugins could be modifying at that point of time. JDT/UI and JDT/lauch are modifying the options at some point of time which I believe shouldn't have happened atleast in this case. Possible Fixes: - Change the behaviour of setOptions(). The API could be modified to start throwing an exception if the options are modified between a getOptions() and setOptions(). - setOptions() could probably be deprecated and replace with setOption(name, value). I don't understand the rational behind not having a setOption(name, value) but only supporting only setOptions(). - JDT/UI pushes the formatter options on the startup. This will fix the problem on a startup but not in the current run. - Splitting the formatter options and the compiler options could help fix atleast formatter options, but I think this could be lot of work. Yes, this will also be an API change. Any better ideas?
(In reply to comment #29) > Possible Fixes: > - Change the behaviour of setOptions(). The API could be modified to start > throwing an exception if the options are modified between a getOptions() and > setOptions(). How would you detect this? An explicit lock? Timestamps? Note that not all calls to getOptions() will be followed by setOptions(). > - setOptions() could probably be deprecated and replace with setOption(name, > value). I don't understand the rational behind not having a setOption(name, > value) but only supporting only setOptions(). I can only guess that the intention was to bundle option changes as to minimize change notifications. But then each storePreference(..) does fire an individual change event. Or is it for performance, because flush(..) may be expensive? How about introducing a second method void setOptions(Hashtable newOptions, boolean clear) using the existing impl. but adding this condition: if (clear) instancePreferences.clear(); to allow changing some options without clearing existing ones? The existing method would then redirect to setOptions(newOptions, true); In this case, care must be taken wrt optionsCache. Either perform an addAll or simply reset to null?
(In reply to comment #30) > How would you detect this? An explicit lock? Timestamps? > Note that not all calls to getOptions() will be followed by setOptions(). Whenever JavaModelManager#optionsCache is updated, an additional property to include the timestamp could be added into the option map. In setOptions() we could see if the timestamp of the map matches to the current JavaModelManager#optionsCache and throw an exception accordingly. > I can only guess that the intention was to bundle option changes as to > minimize change notifications. But then each storePreference(..) does fire > an individual change event. Or is it for performance, because flush(..) may > be expensive? This can be a reasonable explanation. However, the number of options modified through this call has 1-3 number of options in the Eclipse SDK. I am expecting the number to be small. > How about introducing a second method > void setOptions(Hashtable newOptions, boolean clear) > using the existing impl. but adding this condition: > if (clear) > instancePreferences.clear(); > to allow changing some options without clearing existing ones? This also looks good. However, I think we should deprecate the current setOptions() so that it is discouraged. Can there be a better name than passing the flag? > In this case, care must be taken wrt optionsCache. Either perform an > addAll or simply reset to null? Yes, we could just modify the optionsCache to the updated options.
Hello, a little update: I think i finally found out how this bug is triggered. I recently created several workspaces with the following procedure: 1. Start eclipse with new workspace 2. Import preference files containing formatter, compiler preferences, errors/warnings 3. check out from Svn (subclipse plugin) with Team Project File After the checkout i start using eclipse and find that the imported formatter option is not active. It would thus seem that the import of settings forgets to comit these changes to the metadata cache. This should give you an idea where to look for the problem. I will try to test if i can reproduce on windows platform also (i mainly use Linux where i have seen this problem numerous times)
Indeed this is very easy to reproduce on windows also. I just started new workspace and imported preferences. Made a new java project and saw that the formatter did not work as expected. In options it appear as the right formatter is chosen, but only after changing forth and back between formatters, it will apply.
This bug is still present in newest version.
Bug still present in Eclipse Juno (4.2) SR2 Build id: 20130225-0426
Jesper, please take a look, TIA.
Still present in Kepler Release on all platforms. Eclipse IDE for Java Developers Version: Kepler Release Build id: 20130614-0229 Steps to reproduce: 1. Make new workspace 2. Import preferences (.epf file). The preference should specify non-default formatter options (ie spaces instead of tabs). 3. Make new java project. Notice the code is not formattet right. 4. Check preferences. Notice it is set to the imported preferences . Change to eclipse default and apply. Change back and apply. 5. Reformat code - See that code is now formatter as the preferences dictate. Likely cause: When importing preferences, they are not properly committed to cached settings, and therefore does not take effect until preferences is changed forth and back and thus committed to cache. Possible fix: Find the Preference-code that flushes formatter settings to cache and call that method after import of settings.
Is anybody actually working on this issue? Any pointers where to look in the sources (I assume this may involve code outside JDT, right?)? Also, shouldn't the summary be updated? Thanks.
(In reply to Flávio trusco from comment #38) > Is anybody actually working on this issue? Any pointers where to look in the > sources (I assume this may involve code outside JDT, right?)? > Also, shouldn't the summary be updated? Thanks. No, not at the moment. We are busy with fixing Java 8 bugs. Manoj, can you see if you can help Flávio with his question? This can be taken up only after Luna, though.
Mateusz: can you please have a look and check the relevance with the new formatter? Retargetted to 4.7
*** Bug 486641 has been marked as a duplicate of this bug. ***
(In reply to Manoj Palat from comment #40) > Mateusz: can you please have a look and check the relevance with the new > formatter? Retargetted to 4.7 The problem is related to how the options are loaded, not the formatter itself, so the formatter redesign could not affect this bug. Bug 486641 suggests it's still relevant.
*** Bug 515222 has been marked as a duplicate of this bug. ***
Bulk move out of 4.8
*** Bug 366813 has been marked as a duplicate of this bug. ***
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.
