Bugzilla – Full Text Bug Listing
| Summary: | Infinite loop in JDT completion parser recovery/resume | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | i AqD <iiiaqd> | ||||
| Component: | Core | Assignee: | Stephan Herrmann <stephan.herrmann> | ||||
| Status: | VERIFIED DUPLICATE | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | gayanper, jarthana, mauromol, stephan.herrmann | ||||
| Version: | 4.5.1 | ||||||
| Target Milestone: | 4.20 M3 | ||||||
| Hardware: | PC | ||||||
| OS: | All | ||||||
| See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=535743 https://bugs.eclipse.org/bugs/show_bug.cgi?id=542574 https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/180903 https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=f405e82c76aed68376e8e17e0ebf3b01f613d19e |
||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
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. Problem still exists, just that code area is very fragile, and nobody has yet found the time to closely investigate. Re-testing after bug 535743 I no longer see an endless loop, which is plausible, since the CompletionParser:createSnapShotParser() business has been reworked. Instead, I see the invocation *with* a monitor hitting the threshold leading to a HALT. Still we get the dialog that completion took too long, and the parse tree is still insufficient for creating any proposals. This still isn't perfect, but no longer a major problem 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. Retesting on today's HEAD the situation has further improved: recovery no longer loops infinitely nor triggers the threshold. Still we don't get any completions. @Gayan, would you like to give it a try (for 4.21)? I don't recall specific treatment for type arguments in recent fixes, so perhaps this was a blind spot in bug 539685 and vicinity? I spoke too soon. I have a JUnit that fails, BUT in a runtime workbench, we *do* get completions. I'll try to fix my JUnit which would then close this issue :) New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/180903 Gerrit change https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/180903 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=f405e82c76aed68376e8e17e0ebf3b01f613d19e (In reply to Eclipse Genie from comment #8) > Gerrit change https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/180903 was > merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=f405e82c76aed68376e8e17e0ebf3b01f613d19e Passing test has been released, no code changes, which makes this a duplicate of bug 539685. *** This bug has been marked as a duplicate of bug 539685 *** Verified for 4.20 RC1 with build I20210525-1800 |
Created attachment 258174 [details] point mouse to "Date" to trigger the infinite loop in CompletionParser The recovery/resume in CompletionParser could stuck under certain circumstances and fail to quit. The attached example is one of them: the bug is not that JDT fails to parse code but unable to stop attempting recovery and thus freeze the entire program. It triggers the following code: org.eclipse.jdt.internal.compiler.parser.Parser:parse() on a CompletionParser instance: switch (resumeOnSyntaxError()) { case HALT: ...... break; case RESTART: ...... continue ProcessTerminals; case RESUME: ...... continue ProcessTerminals; } Thus I assume the job of stopping repeated resuming failures is on resumeOnSyntaxError(), unfortunately it does not do that in the case of CompletionParser: org.eclipse.jdt.internal.codeassist.complete.CompletionParser:resumeOnSyntaxError(): if (this.monitor != null) { if (++this.resumeOnSyntaxError > 100) { this.resumeOnSyntaxError = 0; if (this.monitor.isCanceled()) return HALT; } } super.resumeOnSyntaxError(); Its super method, the Parser:resumeOnSyntaxError, never returns HALT unless there is a syntax error, while the CompletionParser:resumeOnSyntaxError cannot stop itself (by returning HALT) unless a monitor is used - but monitor is never used in CompletionParser:updateRecoveryState -> CompletionParser:createSnapShotParser cycle which seems to have something to do with lambda. The solution seems easy, just returning HALT once resumeOnSyntaxError hits 100 whether there is monitor or not.