Community
Participate
Working Groups
Build Identifier: 20100917-0705 This is a very serious bug, and I've seen it happen about five times in the past month, but I'm not sure how to reproduce it. When editing a Java file, I step through several stages (maybe a couple dozen or so undos, followed by some redos.) It only started happening in the past month or two (maybe related to new add-on tools or updates?) The next thing that happens is that the file becomes ridiculously corrupted; text is moved all over the place and scrambled. If I haven't saved recently, the file is almost hopelessly corrupted. I wish I could give better guidance about how to reproduce it. It may require pasting text as part of the steps being undone. Let me know what, if any, additional environment details you need. Maybe we'll all be lucky and this will be a known bug. Reproducible: Always
I'm sorry but it is not a know bug and without more details there is nothing we can do. See also: http://www.eclipse.org/eclipse/platform-text/development/bug-incomplete.htm
(In reply to comment #0) > The next thing that happens is that the file becomes ridiculously corrupted; > text is moved all over the place and scrambled. If I haven't saved recently, > the file is almost hopelessly corrupted. Where does the corruption occur? Everywhere in the file? Or only at the top where the import statements are and the class declaration? Does it usually happen after an 'Organize Imports' or formatting operation? When you say corruption what do you mean? Random letters, numbers, and symbols are inserted? Or are characters just getting removed randomly? Or both?
The corruption appears to occur throughout the entire file. They are not random garbage characters, but snippets of the code shuffled around randomly all throughout the file. As additional info, I do have organize imports automatically upon save set, and it's very possible that there was a save that triggered the organize imports in between the undo/redo operations.
I'm sorry you're seeing this but as said before: without more info, we really can't do anything. As a first step, I suggest to read the link from comment 1 and provide all the info mentioned there.
If you have more info/steps then please add them here. Without more details, there's nothing we can do.
Here's my best attempt at describing how to reproduce it. It is intermittent, and I can't seem to force it to happen on demand, but: 1. Enable "Organize imports" checkbox on save in the Preferences: Java Editor, Save Actions 2. Edit an existing file (maybe it's necessary to cause changes in the imports) 3. Save the file at some point in the editing. 4. Continue editing. 5. Cycle through several repeated undo-redo commands. 6. Repeat steps two through five until you see the bug. At some point, like I said, the editor will become hopelessly corrupt and undo/redo will not recover the data. The only recourse is to revert to the saved file. The corruption is as if random snippets of the file were copied and pasted into random places in the file. It looks like somehow the undo/redo buffers are being pushed into the wrong spots. If I were to speculate, I might think that somehow the "organize imports" command might be doing something wrong in its interaction with the undo buffers.
Please answer the questions from http://www.eclipse.org/eclipse/platform-text/development/bug-incomplete.htm e.g. log is important.
See comment 7. It doesn't make sense if you reopen the bug again without providing more information.
This is almost certainly related to the organize imports on save in the Java editor. I didn't experience the problem when this feature is disabled. There are no relevant entries in the log. It still happens in Build id: 20110615-0604. I updated my instructions: 1. Enable "Organize imports" check box on save in the Preferences: Java Editor, Save Actions 2. ** Make some code changes to an existing source file. ** 3. ** Paste an unnecessary import. ** 4. Save the file at some point in the editing. 5. ** Continue editing. ** 6. Cycle through several repeated undo-redo commands crossing over the auto-removal of the import. 7. Repeat steps two through six until you see the bug.
I just wanted to update this. In my installation of a newer version (20110615-0604) of Eclipse (with organize imports still enabled), this no longer happens.
Thanks for reporting back.
Sorry, I guess I jinxed it. The problem returned (in 20110615-0604) Jeff
(In reply to comment #12) > Sorry, I guess I jinxed it. The problem returned (in 20110615-0604) > > Jeff Maybe you installed something again on top of the fresh install from comment 10. I can't reproduce with the steps from 9. Can you? If so, please add some intermediate steps.
.
So this happens almost daily to me. To reproduce: 1. Make sure that automatically organize imports on save action is enabled and that project menu, "build automatically" is checked. Ideally do the below steps on a large-ish project that takes at least ten seconds to build. This problem might be due some concurrency issues that only show up when you perform these steps while the build is executing. 2. Edit a file that has some imports. Save. 3. Add some code that requires new imports. Use ctrl-shift-o to organize imports manually and resolve them. Save. 4. Add some code that requires new imports. Use ctrl-shift-o to organize imports manually and resolve them. Save. 5. Delete a line of code that will cause an import to be removed. Save. 6. Repeat step 5 on another line. Save. 7. Undo several steps, save. Quickly execute the following step while the build is running: 8. Redo several steps, save. 9. Repeat steps 7 and 8 until you see that the text in the file you have been editing has become jumbled (code snippets are randomly inserted in the wrong place in the file).
I tried on several large projects using 3.8 M5 but can't reproduce. Sorry, but the only way we can do anything if we get a complete test case (i.e. also contains the test data), or you try to remote debug the problem so that you can give us more hints.
(In reply to comment #16) > or you try to remote debug the problem so that you can > give us more hints. See: http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Fconcepts%2Fcremdbug.htm
I have found a way to reproduce a similar symptom that I suspect comes from the same root cause. 1. Make sure that automatically organize imports on save action is enabled and that project menu, "build automatically" is checked. Ideally do the below steps on a large-ish project that takes at least ten seconds to build. This problem might be due some concurrency issues that only show up when you perform these steps while the build is executing. 2. Add some code that requires new imports. Use ctrl-shift-o to organize imports manually and resolve them. *Immediately* after you hit ctrl-shift-o, hit ctrl-s to Save. In my case this reliably corrupts the code between the import section and the class definition.
(In reply to comment #18) > I have found a way to reproduce a similar symptom that I suspect comes from the > same root cause. > > > 1. Make sure that automatically organize imports on save action is enabled and > that project menu, "build automatically" is checked. Ideally do the below steps > on a large-ish project that takes at least ten seconds to build. This problem > might be due some concurrency issues that only show up when you perform these > steps while the build is executing. > 2. Add some code that requires new imports. Use ctrl-shift-o to organize > imports manually and resolve them. *Immediately* after you hit ctrl-shift-o, > hit ctrl-s to Save. > > In my case this reliably corrupts the code between the import section and the > class definition. Sorry, no luck. Please see comment 16 again.
This Stack Overflow post/bug might be related to the undo/redo corruption problem: Eclipse 3.5 Copy & Paste Problem http://stackoverflow.com/a/6916909/403455
Reopen this please as it is certainly an issue - maybe related to the bug I reported - see comment here : https://bugs.eclipse.org/bugs/show_bug.cgi?id=407224#c5 It looks like a race condition - that's why one can't reproduce it - but we can't afford file corruption due to race conditions ! I had it happen again today and I noticed the window that lists blocked processes pop up - saying "Building workspace" as the current action and (the rest of) my undos pending - I guess - it just flashed by. Then the file I was editing was left with an extra brace at the end (but I had the symptoms described here hapen to me - that is scrambled lines of code all over the file - happen to me before) Your best chances to reproduce are making a lot of changes to a file - having enabled __"Build automatically"__ and "'Organize Imports'" - then rest your finger on Ctrl-Z - on a *weak machine preferably* - though I had it happen on my main machine. I bet that if you see the "Active processes" pop up you're in for a corrupted file. Didi not look at the error log immediately (sorry - will do next time) but the most recent errors there were : eclipse.buildId=4.3.0.I20130605-2000 java.version=1.7.0_25 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=el_GR Framework arguments: -product org.eclipse.epp.package.jee.product openFile Command-line arguments: -os win32 -ws win32 -arch x86 -product org.eclipse.epp.package.jee.product openFile Error Sat Oct 19 16:48:56 EEST 2013 The resource tree is locked for modifications. eclipse.buildId=4.3.0.I20130605-2000 java.version=1.7.0_25 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=el_GR Framework arguments: -product org.eclipse.epp.package.jee.product openFile Command-line arguments: -os win32 -ws win32 -arch x86 -product org.eclipse.epp.package.jee.product openFile Error Sat Oct 19 16:46:35 EEST 2013 Marker id 119319 not found. eclipse.buildId=4.3.0.I20130605-2000 java.version=1.7.0_25 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=el_GR Framework arguments: -product org.eclipse.epp.package.jee.product openFile Command-line arguments: -os win32 -ws win32 -arch x86 -product org.eclipse.epp.package.jee.product openFile Error Sat Oct 19 15:56:35 EEST 2013 The resource tree is locked for modifications. Thanks
I'm seeing the same issue on Kepler SR 1 (Build id: 20130919-0819) I already opened Bug 332653 for this a long time ago.
It's near end of 2014 and this bug still exists. Hard to reproduce, but certainly an existing bug. And as this is annoying as hell it really needs to be fixed. You edit from State A to B, C, D, E up to Z and go to undo until whatever, M, and redo until S. And in the middle of somewhere there you suddenly land in State !?%$ where everything is corrupted. You can't go forward or backwards or let's say if you do, things get even more corrupted. So either you go back to last save instance OR try to rebuild these snippets on your own (which is possible but very annoying!). Would be like christmas to see this bug being fixed. This was my very reason to create an account here. As I can't imagine that none of you could possibly reproduce this... It must happen at some time, just play arrount with undo/redo... Best
I can confirm the issue still exists. When I undo redo many changes quickly the buffer often gets corrupted.
Reproduced in 4.4. I think if someone on the eclipse team uses eclipse to perform a real-world major refactor of some code, with as many save actions for formatting and organizing on as they possibly can, I'd be pretty amazed if they can't reproduce this, as I've seen it several times. This is a very severe bug and should most definitely not be "RESOLVED WORKSFORME" with so many reports of ongoing problems.
Request to reopen submitted as Bug 443427 - Undo/redo and Save Actions corrupting files (REOPEN 353379)
(In reply to Robert Platt from comment #25) > Reproduced in 4.4. That's wonderful! Please attach the detailed steps into the bug you reopened.
See also: https://bugs.eclipse.org/bugs/show_bug.cgi?id=97538 - maybe related ?
I can't give a packaged-up project to reproduce this at this moment, because it is on source code which I cannot release. In general terms, turn on all possible save actions (formatting, organize imports, etc.), and mix refactoring steps with editing steps. As others have said, it happens daily. And with it being on several versions, I can imagine that with patience this can be reproduced just be turning on these save actions and using Eclipse to refactor some code.
I don't think Bug 97538 is related, as it doesn't cause corruption...
In steps to reproduce, of course, after mixing refactoring and editing steps, you need to undo as far as possible, and then redo. Since the corruption is when you undo/redo!
*push* I think it's easier to reproduce if you refactor class or method names and undo these things (which is a "harder" task than only undo some typing) Also do it fast, just like "naaah the last 10 minutes were pure BS, let's go baaaaaaaaaaaack ..... uh oh too far, let's go fooooooorth" -> BAM corrupted
This is clearly a problem, not just for me. Please leave this bug open.
(In reply to Glenview Jeff from comment #33) > This is clearly a problem, not just for me. Please leave this bug open. Sure, we can leave it open. But in whatever state this bug is, nothing will happen without steps.
Here's a thought: If you have access to a Windows machine, write an autohotkey script to randomly alternate between these three steps: 1. paste a known sequence of characters (say the alaphabet,) 2. undo 3. redo Let it rip for a while. Write a script or regex to search for anything violating the consecutive sequence, which would demonstrate the corruption. I'd adjust the probability so that #2 occurs less often than the others to ensure you don't keep erasing the whole file with undos.
(In reply to Glenview Jeff from comment #35) > Here's a thought: > > If you have access to a Windows machine, write an autohotkey script to > randomly alternate between these three steps: > > 1. paste a known sequence of characters (say the alaphabet,) > 2. undo > 3. redo > > Let it rip for a while. > > Write a script or regex to search for anything violating the consecutive > sequence, which would demonstrate the corruption. I'd adjust the > probability so that #2 occurs less often than the others to ensure you don't > keep erasing the whole file with undos. I'm looking forward to those scripts being attached here.
Here's the regex, thanks hive mind. (0[^1]|1[^2]|2[^3]|3[^4]|4[^5]|5[^6]|6[^7]|7[^8]|8^[9]|9[^0]) http://stackoverflow.com/questions/28588542/search-for-consecutive-sequence-violation#28589119 I'll try to write an autohotkey script for you sometime soon. It really should be pretty trivial to write, but please confirm you'll run it if I do.
(In reply to Glenview Jeff from comment #37) > Here's the regex, thanks hive mind. > > (0[^1]|1[^2]|2[^3]|3[^4]|4[^5]|5[^6]|6[^7]|7[^8]|8^[9]|9[^0]) > > http://stackoverflow.com/questions/28588542/search-for-consecutive-sequence-violation#28589119 > > > I'll try to write an autohotkey script for you sometime soon. It really > should be pretty trivial to write, but please confirm you'll run it if I do. Yes, I'll definitely run any steps/scripts that allow me to reproduce/see the bug.
I also have some issues with the undo / redo function, at least into the Java Editor. It occurs from time to time... maybe more times recently for me. I use E4.4.1. I've just encountered once again that bug. I was removing / putting back a getter from a bean that has an abstract class as parent and potentially the same getter method (maybe it is part of the problem, maybe not). After redo, the modified code became scrambled. There's also generics into my beans hierarchy. My project is Java 5. Nothing into the Error Log view ! That means for me 2 possibilities : either Undo/Redo function ignores some exceptions or it is not properly synchronized somewhere. It looked like that it was more stable previous E4.x... eclipse.buildId=4.4.1.M20140925-0400 java.version=1.7.0_51 java.vendor=Oracle Corporation BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=fr_FR Framework arguments: -product org.eclipse.epp.package.jee.product Command-line arguments: -os win32 -ws win32 -arch x86_64 -product org.eclipse.epp.package.jee.product
This issue is about 80% reproducible for me. I think it can be reproduced by any save actions, including organize imports or code formatting. You also need build automatically turned on as others have mentioned. You also need a rather large project or a slow computer that struggles to build quickly. It must be slow enough to cause the "User Operation is waiting" dialog to appear. 1. Have a Java source file open. Do some stuff to ensure there is some undo history. 2. Cause an intentional syntax error, and save the file. 3. In the same file, engineer a situation where saving the file would cause large formatting changes by the save actions (simple way is to add bunch of unused imports with organized imports turned on). Remove the syntax errors but don't save the file yet. Eclipse should still put a red X on this file. 4. Ensure build automatically is turned on. 5. Write some code like normal (build up at least 5 undo steps). 6. Save the file (you will see the save-on-format kick in and the project will start building to fix the syntax error). 7. The timing in this step is imperative. You need to press undo at just the right moment, right when the build kicks in. You'll know when you did it right because your undo should get interrupted by the "User Operation is Waiting" dialog. Should be about a second after saving the file. 8. The undo history will become corrupt. Sometimes it causes damage, sometimes the undo doesn't do anything at all. It depends on the shift in content due to the save action. On a related note, you can undo only once after step 6, the auto format will be undone but the file will not show the asterisk to indicate there are unsaved changes. This is a different issue but I think it's related somehow.
*** This bug has been marked as a duplicate of bug 506949 ***
