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 Dev (Build 20110331-2d5732445e32) VM: Java HotSpot(TM) Client VM, 17.1-b03-307, Java(TM) SE Runtime Environment, 1.6.0_22-b04-307-10M3261 OS: Mac OS X User Comments: mfukala: pressed enter at the end of ~50 000 lines css Stacktrace: java.lang.IllegalStateException: index 281300 is out of boundaries 1 at org.netbeans.modules.css.formatting.api.embedding.JoinedTokenSequence.moveIndex(JoinedTokenSequence.java:86) at org.netbeans.modules.css.editor.indent.CssIndenter.getFormatStableStart(CssIndenter.java:127) at org.netbeans.modules.css.formatting.api.support.AbstractIndenter.calculateIndentation(AbstractIndenter.java:306) at org.netbeans.modules.css.formatting.api.support.AbstractIndenter.reindent(AbstractIndenter.java:201) at org.netbeans.modules.css.editor.indent.CssIndentTask.reindent(CssIndentTask.java:51) at org.netbeans.modules.editor.indent.TaskHandler$MimeItem.runTask(TaskHandler.java:546)
Created attachment 107425 [details] stacktrace
I got something similar on a very large file myself. I will investigate it this week. Btw. it looks like you are testing our editor on big files? A friend of mine complained to me last week that opening 2MB HTML file in NB in Mac just killed his IDE (6.9.1) and so I wanted to have a look at that as well just to see what are the bottlenecks. If you are already doing something like this then I would skip it - what are your results? Where is most of the time spent?
I know what's the problem here but even after fixing that indenter can be quite slow or die on some other issues. I would prefer to solve this by simply disabling indenter in certain configurations to very straightforward operating mode like "use indent of previous line". By certain configurations I would mean some threshold in number of lines or size of file etc. What do you think?
(In reply to comment #2) > I got something similar on a very large file myself. I will investigate it this > week. Btw. it looks like you are testing our editor on big files? A friend of > mine complained to me last week that opening 2MB HTML file in NB in Mac just > killed his IDE (6.9.1) and so I wanted to have a look at that as well just to > see what are the bottlenecks. If you are already doing something like this then > I would skip it - what are your results? Where is most of the time spent? 2MB html file is not so big. I've tried even bigger, but it definitively depends on the structure and the amount of embeddings. Is it possible to share the file at least privately? As for the testing, I just run into some performance problems when evaluating some OOM reports, I haven't spent much time on it. Apart from the two formatting - related issues I've discovered the editor seemed quite usable. However I primarily tested CSS files, not html.
(In reply to comment #3) > I know what's the problem here but even after fixing that indenter can be quite > slow or die on some other issues. I would prefer to solve this by simply > disabling indenter in certain configurations to very straightforward operating > mode like "use indent of previous line". By certain configurations I would mean > some threshold in number of lines or size of file etc. What do you think? I've been expecting something like this :-). I think it sounds reasonable simply no to process or process in some limited mode some unusually big inputs if the issue cannot be resolved easily. Possibly disabling the formatting w/ some message to the user and doing the indentation in some naive mode is ok. BTW is the whole file analyzed per each new line keystroke or just some limited context is used?
(In reply to comment #5) > BTW is the whole file analyzed per each new line keystroke or just some limited > context is used? It is "smart" but depends on the file structure and that's why it can fail on some documents. For tag based documents a parent tag enclosing currently edited text is located first. But there is lots of iffs involved when locating this parent tag and if document is shallow and uses lots of tags with optional closing tags like <p> (which must be ignored as it is not obvious if they were closed or not) then it may happen that first stable parent tag is <body> (which is case where indentation ends up analyzing pretty much whole file for each keystroke). HTML with its optional closing/opening tags makes it hard to be reliable. But perhaps the new line keystroke indent should be smarter and if going too much backwards in the document it should abort it and use different strategy - less correct one but faster. Btw. I used document from issue 197458 to evaluate this problem.
I made quite a progress but need to continue with it tomorrow.
This problem is result of very poor algorithm I used (and forgot about it) to identify index in joined token sequences. "Index" in joined token sequence is composed from two parts: #1) index of token sequence used; and #2) token index within the selected token sequence The original algorithm joined those two parts into a single integer which might be OK but problem is that algorithm used imposed a limit on maximum number of tokens in single token sequence to be 99999. That's why this problem only manifests on bigger files. On the other hand once the file is bigger and passes the limit this problem happens always and prevents user from entering single new line (=P1). The fix is very safe and I would like to ask for review and integration into NB7 branch. The fix has two parts: * use index which is array of two integers instead of single integer encoding both values. It not very elegant but it is simple and error free. I think it is better than introducing a dedicated class to hold both indexes. * while refactoring the code I noticed that LexUtilities helper methods were incorrectly calling index() instead of moveIndex(). This issues does not impact return value of the helper methods and that's why it was not noticed before but it changes the state in which token sequence is left. The fix is in web-main: 90adb2abdacd I ran quite extensive unit test suite for CSS, HTML and JSP indentation and all tests passed before and after this change. The fix changes friend API contract so I fixed also php.smarty client in main/contrib: 49e240109890 I will attach a test HTML document on which the fix can be verified. Martin could you review please? Marek is on holiday I think.
Created attachment 107599 [details] zipped HTML document Open this document and try pressing Enter in random lines. Once you are 10000 lines and lower it used to throw the exception. The file causes other performance issues which are being evaluated under issue 197458.
Counter argument for not including this bugfix in the NB70 is that the problem existed in our source base since NB67 and nobody reported it before. Up to QA to make final decision.
Ok, so I was reviewing these several changes for quite a long while. :) Fully agree that the previous solution was pretty ugly but not agree that the current solution wouldn't be elegant. It looks so readable and efficient now (than to work with Strings there or use classes for wrapping ints). I think that this first part of changes cannot change anything on behaviour of indenters. The change of index() to moveIndex() is of course correct, but to be honest to QE it's chance that it could change behaviour somewhere. But I didn't follow all usages of these functions and I'm sure that David as a author would know about potential troubles. Also I believe that his legion of JUnit test would detect any problems. As David told, decision is up to QE. I can just say that David made good patch and everything possible to catch all consequences. Reviewed and also verified. BTW, thank you David for fixing php.smarty module.
(In reply to comment #10) > Counter argument for not including this bugfix in the NB70 is that the problem > existed in our source base since NB67 and nobody reported it before. Up to QA > to make final decision. Thanks for evaluation, I think - because we already have an FCS build: I would leave it open for NB 7.0 and fix it into 7.0.1
Integrated into 'main-golden', will be available in build *201104080400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/90adb2abdacd User: David Konecny <dkonecny@netbeans.org> Log: #197323 - IllegalStateException: index 281300 is out of boundaries 1
This bug is completely different to 107605: - The stack trace is different. - #107605 is about SVG, not HTML. - #107605 is about DnD, not inserting some text manually.
Sorry, accidently posted to the wrong bug report.
I tested it on attached zipped HTML and no errors were thrown, verified... Product Version: NetBeans IDE 7.0.1 (Build 201107211357) Java: 1.7.0; Java HotSpot(TM) Client VM 21.0-b17 System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb)
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/4534a9ea8012 User: David Konecny <dkonecny@netbeans.org> Log: #197323 - IllegalStateException: index 281300 is out of boundaries 1
*** Bug 196272 has been marked as a duplicate of this bug. ***