Bugzilla – Full Text Bug Listing
| Summary: | [rename] Undo for rename type... called from outside the editor doesn't work | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Kris De Volder <kdevolder> | ||||
| Component: | Text | Assignee: | Markus Keller <markus.kell.r> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | daniel_megert, kdevolder | ||||
| Version: | 3.6 | Keywords: | investigate | ||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
On a hunch, I also tried "Drag and Dropping" the file into another package. This also triggers the bug. It seems that you need the following conditions to trigger the bug: 1) Refactoring doesn't start from editor 2) Refactoring involves 'Moving' a file. 3) There are references inside the moved file that get updated by the refactoring. 4) The moved file is open in the Java editor. (I.e. if you don't have the 'me' field in the example class, then the bug isn't triggered). I also filed another bug recently, which may be related (could have a common cause, though that is just a guess). https://bugs.eclipse.org/bugs/show_bug.cgi?id=345342 The bugs are similar in that they both involve the same kinds of 'moving types and CUs' and seem to get triggered only when doing them without using the 'inline rename' support (the inline rename support somehow does the right thing in both cases... unfortunately, there's no inline equivalent for "Drag and Drop move refactoring"). Another interesting example:
package foop;
public class Original {
Original() {}
}
This example triggers the bug for Drag and Drop to another package, but NOT for rename CU from the package explorer.
There appears to be some kind of race condition involved. Trying to understand what's going on, I put a breakpoint in In method org.eclipse.ltk.core.refactoring.UndoTextFileChange.initializeValidationData(IProgressMonitor) This gets called when I execute refactoring... But it seems to end up with a different result, depending on where I put my breakpoint. If I put the breakpoint at the start of the method and step through it, then it ends up with time stamp value of "-1" and the bug doesn't happen. However, when I put the breakpoint at the end (inside the finally block), and inspect the timestamp object then it has some other value and the bug is triggered. I think race condition is between the execution of the tread that calls the method mentioned in previous comment and the UI thread, where the editors are responding to moved files via this method: org.eclipse.ui.editors.text.TextFileDocumentProvider$FileBufferListener.underlyingFileMoved(org.eclipse.core.filebuffers.IFileBuffer, org.eclipse.core.runtime.IPath) line: 322 If the editors respond to the move before we compute the time stamp, then we get -1 because they have already deregistered their textbuffer. If however the editors respond to the move later... then we get a real time stamp based on whats in the editor's buffer... I've got stack traces of the critical points in the two competing threads. I will attach them in a separate file. Created attachment 196259 [details]
Thread dumps
Attached the tread dumps. The show the threads stopped at two breakpoints simultaneously.
These both get hit when you rename the sample code from the package explorer, if you have the file open in an editor.
Now depending on which of the threads you restart first to make it 'win the race' you will get a different timestamp and you will get the bug or not.
Markus, can you please investigate. 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. Prompted by the bot message... Just tried the steps exactly as described and this bug is still a problem. Let me also add that anecdtoally, I find the 'undo' for various refactorings in Eclipse has been quite unreliable in my experience for quite a long time. If I had to make a guess, it dates back from the transition of Eclipse 3.x line to Eclipse 4.x. So this bug is probably just the tip of the proverbial iceberg, I just haven't bothered with filing more/similar tickets, given the lack of response I'm getting on this one. Forgot to mention.... when I say 'still reproducible' I was using a build STS 4 based on Eclipse 4.9. |
Build Identifier: Version: 3.6.2 Build id: M20110210-1200 Here's a sample class ---- package foop; public class Original { Original me = null; } --- FROM THE PACKAGE EXPLORER: - Select the compilation unit 'Original.java' and right click to rename it. - Type the new name 'Renamed' - Click Finish - Then immidiately do "Edit >> Undo" Result "Cannot be undone because the contents of 'Original.java' has changed. This is strange because: - Original.java doesn't exist (since it was renamed/moved) - I didn't make *any* changes after performing the refactoring Interesting detail: - to reproduce, the file needs to be open in an editor... if the file is *not* open in an editor then the undo actually works! Reproducible: Always