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.
Build: NetBeans IDE 8.2 (Build 20170403-27016069f105) VM: Java HotSpot(TM) 64-Bit Server VM, 25.112-b15, Java(TM) SE Runtime Environment, 1.8.0_112-b15 OS: SunOS User Comments: vv159170: # 1 // asdf \| pressed Enter Stacktrace: java.lang.IllegalStateException: INCONSISTENCY in token hierarchy occurred at org.netbeans.lib.lexer.inc.TokenHierarchyUpdate.update(TokenHierarchyUpdate.java:148) at org.netbeans.lib.lexer.TokenHierarchyOperation.textModified(TokenHierarchyOperation.java:605) at org.netbeans.spi.lexer.TokenHierarchyControl.textModified(TokenHierarchyControl.java:96) at org.netbeans.lib.lexer.inc.DocumentInput.textModified(DocumentInput.java:152) at org.netbeans.lib.lexer.inc.DocumentInput.removeUpdate(DocumentInput.java:145) at org.netbeans.lib.editor.util.swing.PriorityDocumentListenerList.removeUpdate(PriorityDocumentListenerList.java:116)
Created attachment 164027 [details] stacktrace
Reproduced. Unfortunately there was one glitch that I've fixed yesterday (should be in today's trunk) in terms of issue #267354 - if there was e.g. an AssertionError in the document's modification processing (e.g. in a lexer's processing) then BaseDocument.breakAtomicLock() was called (to undo document modifications done so far within atomic transaction) and if this failed with an exception (it would likely fail since token hierarchy updating did not finish so the token hierarachy would be inconsistent) then the thrown exception has hidden the original AssertionError exception. It was a bit tricky to discover that but it should be fixed in today's trunk and it should hopefully reveal the real problem in issue #267354. I've reproduced your scenario and there's an AssertionError in CndLexer - if you could check that. <<<<<<<<<<<<<<<<<< LEXER CHANGE START ------------------ TEXT INSERTED at 12 len=1 "\\" java.lang.AssertionError: there must be \ org.netbeans.modules.cnd.lexer.CndLexer.nextToken(CndLexer.java:141) org.netbeans.lib.lexer.LexerInputOperation.nextToken(LexerInputOperation.java:216) org.netbeans.lib.lexer.inc.TokenListUpdater.relex(TokenListUpdater.java:627)
(In reply to Miloslav Metelka from comment #2) > Reproduced. Unfortunately there was one glitch that I've fixed yesterday > (should be in today's trunk) in terms of issue #267354 - if there was e.g. > an AssertionError in the document's modification processing (e.g. in a > lexer's processing) then BaseDocument.breakAtomicLock() was called (to undo > document modifications done so far within atomic transaction) and if this > failed with an exception (it would likely fail since token hierarchy > updating did not finish so the token hierarachy would be inconsistent) then > the thrown exception has hidden the original AssertionError exception. > It was a bit tricky to discover that but it should be fixed in today's trunk > and it should hopefully reveal the real problem in issue #267354. > I've reproduced your scenario and there's an AssertionError in CndLexer - if > you could check that. > > <<<<<<<<<<<<<<<<<< LEXER CHANGE START ------------------ > TEXT INSERTED at 12 len=1 "\\" > java.lang.AssertionError: there must be \ > org.netbeans.modules.cnd.lexer.CndLexer.nextToken(CndLexer.java:141) > org.netbeans.lib.lexer.LexerInputOperation.nextToken(LexerInputOperation. > java:216) > org.netbeans.lib.lexer.inc.TokenListUpdater.relex(TokenListUpdater.java:627) Thanks, Mila, This is how I got here myself: by working on https://netbeans.org/bugzilla/show_bug.cgi?id=269731 (AssertionError: there must be \) So, I think, I can close this as duplicate of 269731, right? Nothing bad in netbeans Lexer module, right?
*** This bug has been marked as a duplicate of bug 269731 ***