This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Own build from 19 July. Sometimes, the tip completion query starts to consume 100% of CPU "forever". I do not have a reproducible test case. I am attaching a few stack traces that shown the suspect thread.
Created attachment 23236 [details] Suspect stack traces.
*** Issue 62956 has been marked as a duplicate of this issue. ***
This is a potential beta stopper. Must be evaluated ASAP and fixed if possible.
it looks that under some condition there is a neverending loop in JavaCompletionQuery.tipQuery(): while (cont) { sup.tokenizeText(tp, (((lastSepOffset + 1) <= offset) ? lastSepOffset + 1 : offset), offset, true); if (cont = tp.isStopped()) { lastSepOffset = sup.findMatchingBlock(tp.getCurrentOffest(), true)[0]; } }
Honza, in what JDK version did you reproduced it? It seems the issue depends on the specific tokens conditions before caret position... If you will reproduce it again try to find out what exact expression you completed and tokens before.
Surely you can insert some code before the loop that estimates an upper bound on how many times the loop could possibly run, and if that is exceeded, break the loop and notify an exception with as much diagnostic info as you need? Then if it happens again we won't have to guess why.
I have added the safety counter to the while() cycle. It will list the problematic offset and inform the user to attach the particular source file to this issue so that we can track the problem. The infinite loop will be broken so the user should be able to continue editing. I mark this as fixed for now until we obtain the problematic case.
in trunk: Checking in lib/src/org/netbeans/editor/ext/java/JavaCompletionQuery.java; /cvs/java/editor/lib/src/org/netbeans/editor/ext/java/JavaCompletionQuery.java,v <-- JavaCompletionQuery.java new revision: 1.6; previous revision: 1.5