Community
Participate
Working Groups
Build Identifier: I20100513-1500 (Eclipse 3.6RC1) Enviroment: * Eclipse 3.6RC1 64-bit Cacoa * Mac OS X 10.5.8 * Java 1.6.0_17-b04-248-9M3125 * Clean install: no Eclipse plugins installed, empty .metadata directory * My workspace is pretty large (10000+ files, a mix of Java, XML, etc), although I've been able to reproduce this in a workspace with only one open project containing just one Java file. Symptoms: The bug manifests randomly (race condition?) when opening Java files (see attached stack trace). The bug only applies to the Java editor, as the files open fine in the standard text editor (right-click -> Open with... -> Text Editor). To make things worse, the SAME FILE will sometimes open successfully and then crash the next time its opened. So, it looks like the contents of the file have nothing to do with the crash. It doesn't matter how the file is opened: double-click from explorer, open declaration (F3), etc. Cursory analysis: I couldn't find the same bug mentioned anywhere in Bugzilla or on the internet, so perhaps it's just me. Here are some old bugs with the same stack trace, but steps to reproduce are quite different from mine: https://bugs.eclipse.org/bugs/show_bug.cgi?id=67043 http://scala-ide.assembla.com/spaces/scala-ide/tickets/115-single-line-comment-broken-in-plugin I checked out the source code for ProjectionTextStore:152 and the root case is a apparently BadLocationException, which is unfortunately swallowed by the internalError() method :( Per the docs, BadLocationException indicates that an invalid document position is being accessed (negative? Past EOF?) Anyway, without more context or familiarity with the codebase, it will be difficult for me to track this down. Does anyone more familiar with the editor initialization code have any idea what could be causing this? Reproducible: Sometimes Steps to Reproduce: 1. Double-click on a Java file 2. Java editor crashes when opening (see attached stack trace)
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.
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.
