Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 313972

Summary: [projection] Java editor randomly crashes when opening certain Java files (throws IllegalStateException)
Product: [Eclipse Project] JDT Reporter: Nick Dellamaggiore <wontonsoup79>
Component: TextAssignee: 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.6Flags: markus.kell.r: review+
darin.eclipse: review+
Target Milestone: 3.6 RC4   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
Stack trace
none
Screenshot of crashed editor window
none
Screenshot of my folding preferences
none
Java file that reproduces the issue
none
Fix
none
Fix none

Description Nick Dellamaggiore CLA 2010-05-21 15:30:54 EDT
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)
Comment 1 Nick Dellamaggiore CLA 2010-05-21 15:32:20 EDT
Created attachment 169554 [details]
Stack trace
Comment 2 Nick Dellamaggiore CLA 2010-05-21 15:35:25 EDT
Created attachment 169555 [details]
Screenshot of crashed editor window
Comment 3 Nick Dellamaggiore CLA 2010-05-21 15:36:37 EDT
FWIW, the user-facing error in the editor window is "Could not open the editor: An unexpected exception was thrown". See attached screenshot.
Comment 4 Olivier Thomann CLA 2010-05-21 16:56:03 EDT
Moving to Platform/Text
Comment 5 Dani Megert CLA 2010-05-22 02:59:12 EDT
- 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?
Comment 6 Dani Megert CLA 2010-05-22 03:05:57 EDT
Bug 279676 is about a very similar problem. Could you test with a different Mac and see whether it happens there as well?
Comment 7 Nick Dellamaggiore CLA 2010-05-23 05:46:11 EDT
(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.
Comment 8 Nick Dellamaggiore CLA 2010-05-23 05:47:15 EDT
Created attachment 169607 [details]
Screenshot of my folding preferences
Comment 9 Nick Dellamaggiore CLA 2010-05-23 05:50:15 EDT
(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
Comment 10 Dani Megert CLA 2010-05-24 03:03:25 EDT
>/**
>* $$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?
Comment 11 Nick Dellamaggiore CLA 2010-05-24 15:46:43 EDT
(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.
Comment 12 Nick Dellamaggiore CLA 2010-05-24 16:26:37 EDT
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.
Comment 13 Dani Megert CLA 2010-05-31 08:46:04 EDT
*** Bug 314931 has been marked as a duplicate of this bug. ***
Comment 14 Dani Megert CLA 2010-05-31 08:46:29 EDT
Test Case:

public class Foo {

    @SuppressWarnings
    private int a;

}
Comment 15 Dani Megert CLA 2010-05-31 12:39:16 EDT
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.
Comment 16 Dani Megert CLA 2010-05-31 12:39:56 EDT
Created attachment 170561 [details]
Fix
Comment 17 Markus Keller CLA 2010-05-31 13:12:46 EDT
(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.
Comment 18 Dani Megert CLA 2010-05-31 13:24:17 EDT
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.
Comment 19 Dani Megert CLA 2010-05-31 15:39:33 EDT
Darin, can you please look at the patch? At this time assume it's for bug 314931 
only.
Comment 20 Darin Wright CLA 2010-05-31 15:44:57 EDT
+1 for fixing the issue with bug 314931.
Comment 21 Dani Megert CLA 2010-06-01 03:02:51 EDT
Reopened bug 314931 for which the patch was made. Keeping this bug open for further investigations.

Darin, I noted your +1 in bug 314931.
Comment 22 Dani Megert CLA 2010-06-01 09:26:07 EDT
*** Bug 314931 has been marked as a duplicate of this bug. ***
Comment 23 Dani Megert CLA 2010-06-01 09:41:54 EDT
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.
Comment 24 Dani Megert CLA 2010-06-01 09:42:13 EDT
.
Comment 25 Dani Megert CLA 2010-06-01 09:43:06 EDT
Created attachment 170635 [details]
Fix
Comment 26 Darin Wright CLA 2010-06-01 10:29:34 EDT
+1. I'm not familiar with ProjectionDocuments, but the logic makes sense.
Comment 27 Markus Keller CLA 2010-06-01 10:43:16 EDT
+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).
Comment 28 Dani Megert CLA 2010-06-01 10:48:29 EDT
Fixed in HEAD.
Available in I-builds > I20100601-0800.
Comment 29 Nick Dellamaggiore CLA 2010-06-01 15:54:45 EDT
(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!
Comment 30 Dani Megert CLA 2010-06-02 04:19:06 EDT
Verified in N20100601-2000. Waiting for final verification in next I-build.
Comment 31 Dani Megert CLA 2010-06-03 06:44:10 EDT
Verified in I20100603-0100.