| Summary: | [projection] Java editor randomly crashes when opening certain Java files (throws IllegalStateException) | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Nick Dellamaggiore <wontonsoup79> | ||||||||||||||
| Component: | Text | Assignee: | Dani Megert <daniel_megert> | ||||||||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||||||||
| Severity: | major | ||||||||||||||||
| Priority: | P2 | CC: | daniel_megert, darin.eclipse, karenfbutzke, markus.kell.r, Olivier_Thomann, remy.suen, wontonsoup79 | ||||||||||||||
| Version: | 3.6 | Flags: | markus.kell.r:
review+
darin.eclipse: review+ |
||||||||||||||
| Target Milestone: | 3.6 RC4 | ||||||||||||||||
| Hardware: | All | ||||||||||||||||
| OS: | All | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
Nick Dellamaggiore
Created attachment 169554 [details]
Stack trace
Created attachment 169555 [details]
Screenshot of crashed editor window
FWIW, the user-facing error in the editor window is "Could not open the editor: An unexpected exception was thrown". See attached screenshot. Moving to Platform/Text - Can you reproduce it with this build: http://download.eclipse.org/eclipse/downloads/drops/I20100520-1744/index.php - Is it not just the same file but also the same content? - How are your folding preferences set (Java > Editor > Folding). Picture is OK. - Does the problem go away if you disable folding? - When it happens, are you sure the same file is not open in any other editor, including compare? Bug 279676 is about a very similar problem. Could you test with a different Mac and see whether it happens there as well? (In reply to comment #5) > - Can you reproduce it with this build: > http://download.eclipse.org/eclipse/downloads/drops/I20100520-1744/index.php Yes. Same file -> same stack trace > - Is it not just the same file but also the same content? Not sure I understand your question. I can reproduce with many different Java files > - How are your folding preferences set (Java > Editor > Folding). Picture is > OK. See attached - Does the problem go away if you disable folding? Bingo! After disabling folding, I was able to open the file 10 times in a row without a crash. I'll leave folding off for now. It's a little inconvenient, but not nearly as bad as the crashing :) Thanks! Actually, I think this folding hint helped me track down the file content causing the issue. All the files that crash are older files in our codebase that have an SVN $Id line at the top of the file, before the package declaration e.g. /** * $$Id: SomeClass.java 56698 2008-10-15 21:32:44Z somebody $$ */ I think this might be throwing off the folding code. Hope that helps you track this down. > - When it happens, are you sure the same file is not open in any other editor, > including compare? I closed all windows and was able to reproduce the editor crash on first opening the file. Created attachment 169607 [details]
Screenshot of my folding preferences
(In reply to comment #6) > Bug 279676 is about a very similar problem. Could you test with a different Mac > and see whether it happens there as well? I will try this out at work on Monday. Do check out my reply to comment #5, as I think I may have found a more reproducible test case >/** >* $$Id: SomeClass.java 56698 2008-10-15 21:32:44Z somebody $$ */ > >I think this might be throwing off the folding code. Hope that helps you track >this down. Could you try to remove that part and check whether this makes the problem go away even if folding is enabled? (In reply to comment #10) > Could you try to remove that part and check whether this makes the problem go > away even if folding is enabled? Yes, this does make the problem go away. I turned folding on and removed the comments above the package declaration. I tested opening the file ten times; it worked every time. Created attachment 169727 [details]
Java file that reproduces the issue
Per your request, I just tested this on another machine with the same specs. I did a clean install of the 3.6 integration build and started a new workspace. Folding preferences are set per the attached screenshot.
I created a new Java project and created the attached file (Foo.java) in the "foo" package. The file represent a minimal test case: an empty class body with a few imports and Java comments before the package declaration.
I opened/closed the file 3 times and it worked. On the fourth open, the editor crashed. It crashed on and off on subsequent opens. Can you try reproducing the issue with this attached file? Thanks!
Btw, my colleague is running Eclipse 3.5 (same OS and Java version) and we cannot reproduce the issue on his machine.
*** Bug 314931 has been marked as a duplicate of this bug. *** Test Case:
public class Foo {
@SuppressWarnings
private int a;
}
This is severe enough to get fixed during RC4. I've investigated the problem and found the bug: under some conditions we create a projection with length 0 which is not tolerated by the viewer. The fix is obvious, small and very low risk. Risk: The risk of the change is very low since the projection with length 0 isn't supported by the ProjectionViewer anyway, hence ignoring it doesn't harm. There is no performance impact due to this fix. Created attachment 170561 [details]
Fix
(In reply to comment #16) > Created an attachment (id=170561) [details] [diff] > Fix Even with this patch, I get the stacktrace from comment 1 when I try to open the file from comment 12 (I20100527-1700 WinXP + many plug-ins from HEAD). I get the exception about 50% of the times I try to open that file. I never got it when I opened comment 14. In both cases, a breakpoint at the beginning of DefaultJavaFoldingStructureProvider.JavaElementPosition#computeProjectionRegions(IDocument) is never hit. I only ever got into the changed code when collapsed the folding in comment 14. In that case, the patch fixed the problem. So, this looks like a fix for bug 314931 but not for this bug. I admit that I only used the reproducible case from comment 14. So this looks indeed like two different issues. Suggest to split this again, fix bug 314931 and then investigate further on this bug here. Darin, can you please look at the patch? At this time assume it's for bug 314931 only. +1 for fixing the issue with bug 314931. Reopened bug 314931 for which the patch was made. Keeping this bug open for further investigations. Darin, I noted your +1 in bug 314931. *** Bug 314931 has been marked as a duplicate of this bug. *** Further investigation revealed that bug 314931 actually boils down to be the same problem. Two different issues are causing the problems: 1) The DefaultJavaFoldingStructureProvider creates invalid 0-length segments at the end. My first patch fixed this issue for Java code but not for Java comments. Same fix needs to be applied to DefaultJavaFoldingStructureProvider.CommentPosition.computeProjectionRegions(...). 2) A bug in ProjectionDocument.ensureWellFormedSegmentation(int) which got introduced with the fix for bug 301023. Before fixing said bug, this method corrected the wrong segments from 1). We could either only fix 1) or only 2) or both. Given that the fix for bug 301023 came in quite late (22 March 2010), I suggest to fix 2) and for complete correctness also 1). Risk assessment: Fixing 1) is very low risk since we simply get rid of the invalid segments which get removed anyway in ProjectionDocument.ensureWellFormedSegmentation(int) (3.5.2 and once we fix 2). Fixing 2) is also very low risk since it only brings us closer to the 3.5.2 code again without bringing back bug 301023. . Created attachment 170635 [details]
Fix
+1. I'm not familiar with ProjectionDocuments, but the logic makes sense. +1 for RC4. I felt uneasy with the first patch, but the fix from comment 25 is solid, solves all known cases and keeps bug 301023 fixed. The fixes in DefaultJavaFoldingStructureProvider alone would only fix the reported problems, but I'm pretty sure other clients would run into the bug in ProjectionDocument as well. I fully agree with comment 23 (fix both). Fixed in HEAD. Available in I-builds > I20100601-0800. (In reply to comment #28) > Fixed in HEAD. > Available in I-builds > I20100601-0800. You guys rock! Thanks for taking care of this in 3.6! Verified in N20100601-2000. Waiting for final verification in next I-build. Verified in I20100603-0100. |