Community
Participate
Working Groups
Created attachment 276466 [details] Eclipse installation details I typed a line of java which was not syntactically correct and it caused my eclipse to freeze completely. Windows reported that it was "Not Responding" and the only thing I could do was kill it using TaskManager. When I re-started eclipse the build would run to a certain percentage then gang there. All other operations were blocked since the build never completed. The offending line was: stream.forEach((list::add); Note that the parens do not match (one too many open paren). I had to edit the java file outside of eclipse. With the typo fixed, eclipse starts and builds normally. You can find a test-case @ https://github.com/llowrey/eclipse-freeze-test-case Version: 2018-09 (4.9.0) Build id: 20180917-1800
I can reproduce. Thread "Compiler Processing Task" seems to have an infinite loop in Parser.parse() line: 11561 Parser.parseExpression(char[], int, int, CompilationUnitDeclaration, boolean) line: 12239 ReferenceExpression.copy() line: 152 ReferenceExpression.cachedResolvedCopy(TypeBinding) line: 948 ReferenceExpression.isCompatibleWith(TypeBinding, Scope) line: 1231 PolyTypeBinding.isCompatibleWith(TypeBinding, Scope) line: 43 BlockScope(Scope).parameterCompatibilityLevel(TypeBinding, TypeBinding, LookupEnvironment, boolean) line: 4917 BlockScope(Scope).parameterCompatibilityLevel(MethodBinding, TypeBinding[], boolean) line: 4884 BlockScope(Scope).computeCompatibleMethod(MethodBinding, TypeBinding[], InvocationSite, boolean) line: 867 BlockScope(Scope).computeCompatibleMethod(MethodBinding, TypeBinding[], InvocationSite) line: 794 BlockScope(Scope).findMethod0(ReferenceBinding, char[], TypeBinding[], InvocationSite, boolean) line: 1750 BlockScope(Scope).findMethod(ReferenceBinding, char[], TypeBinding[], InvocationSite, boolean) line: 1651 BlockScope(Scope).getMethod(TypeBinding, char[], TypeBinding[], InvocationSite) line: 2934 MessageSend.findMethodBinding(BlockScope) line: 954 MessageSend.resolveType(BlockScope) line: 775 MessageSend(Expression).resolve(BlockScope) line: 1034 Block.resolveUsing(BlockScope) line: 138 TryStatement.resolve(BlockScope) line: 1189 MethodDeclaration(AbstractMethodDeclaration).resolveStatements() line: 641 MethodDeclaration.resolveStatements() line: 316 MethodDeclaration(AbstractMethodDeclaration).resolve(ClassScope) line: 551 TypeDeclaration.resolve() line: 1229 TypeDeclaration.resolve(CompilationUnitScope) line: 1354 CompilationUnitDeclaration.resolve() line: 656 Compiler.process(CompilationUnitDeclaration, int) line: 892 ProcessTaskManager.run() line: 145 Thread.run() line: 844 Other threads like "Text Viewer Hover Presenter" have the same problem. Strangely it started OK, even completion worked, until I did Project > Clean. Even despite the infinite loop, I can continue to work in Eclipse. Just the build never finishes (so saving changes is blocked). Clean Exit is also blocked.
To make the bug self-contained: this is the test case: //--- package example; import java.nio.file.Files; import java.nio.file.Path; import java.util.ArrayList; public class TestCase { public static void testCase(Path path) throws Exception { var list = new ArrayList<Path>(); try (var stream = Files.newDirectoryStream(path)) { stream.forEach((list::add); } } } //---
Bulk move out of 4.11
Any workaround for this?
(In reply to Jay Arthanareeswaran from comment #4) > Any workaround for this? Don't write code with syntax errors? ;p Or did you ask for some hack to brute-force abort the infinite parse?
(In reply to Stephan Herrmann from comment #5) > (In reply to Jay Arthanareeswaran from comment #4) > > Any workaround for this? > > Don't write code with syntax errors? ;p > > Or did you ask for some hack to brute-force abort the infinite parse? Sorry, I didn't look closely. I thought there was some content assist involved and that some incomplete code led to this issue. Please ignore this.
Bulk move to 4.14
Bulk move of unassigned bugs to 4.15
Bulk move to 4.16
Bulk move of unassigned bugs to 4.17
Not reproducible anymore on 4.28 RC1
(In reply to Srikanth Sankaran from comment #11) > Not reproducible anymore on 4.28 RC1 Thanks for testing. With this I'll boldly declare this a duplicate of bug 539685. Srikanth, fyi: in bug 539685 comment 29 f. I explained a significant change of strategy. *** This bug has been marked as a duplicate of bug 539685 ***
(In reply to Stephan Herrmann from comment #12) > (In reply to Srikanth Sankaran from comment #11) > > Not reproducible anymore on 4.28 RC1 > > Thanks for testing. With this I'll boldly declare this a duplicate of bug > 539685. > > Srikanth, fyi: in bug 539685 comment 29 f. I explained a significant change > of strategy. > > *** This bug has been marked as a duplicate of bug 539685 *** Sorry, looks like you had to wage a decidedly non fun battle with the completion engine. I had a super clean design in 2014 Oct which I never committed to paper. You will have to take my word that it would have solved all our problems and would have been the cleanest most elegant implementation - with no proof for such claim. A la Fermat.
(In reply to Srikanth Sankaran from comment #13) > (In reply to Stephan Herrmann from comment #12) > > (In reply to Srikanth Sankaran from comment #11) > > > Not reproducible anymore on 4.28 RC1 > > > > Thanks for testing. With this I'll boldly declare this a duplicate of bug > > 539685. > > > > Srikanth, fyi: in bug 539685 comment 29 f. I explained a significant change > > of strategy. > > > > *** This bug has been marked as a duplicate of bug 539685 *** > > Sorry, looks like you had to wage a decidedly non fun battle with the > completion engine. "fun" is a relative concept :) Indeed I was quite happy when in the end eclipse would no longer freeze.. and then I was battling not only with code from 2013/14, I had to make some changes to strategies defined well even before your time. > I had a super clean design in 2014 Oct which I never > committed to paper. You will have to take my word that it would have solved > all our problems and would have been the cleanest most elegant > implementation - with no proof for such claim. A la Fermat. Time to print books with larger margins.
