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.
This bug was originally marked as duplicate of bug 172978, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related. Build: NetBeans IDE Dev (Build 201002152000) VM: Java HotSpot(TM) Client VM, 16.0-b13, Java(TM) SE Runtime Environment, 1.6.0_18-b07 OS: Windows XP User Comments: ashl1: Interrupt debuggibg mjreged: while editing java class GUEST: I was editing a source code. GUEST: writing c++, pasting "cout << endl;" from buffer paul_floyd: Pasting an enum element into a switch case in a C file pif17: don't know why, coding with C module lsvidal: I was using code completition on some classes I created. I can send the source code if you need. Stacktrace: javax.swing.text.BadLocationException: Invalid offset=1889 not within <0, 1888> at org.netbeans.editor.Utilities.checkOffsetValid(Utilities.java:1389) at org.netbeans.editor.Utilities.checkOffsetValid(Utilities.java:1384) at org.netbeans.editor.Utilities.getRowStart(Utilities.java:156) at org.netbeans.editor.Utilities.getRowStart(Utilities.java:139) at org.netbeans.editor.CodeFoldingSideBar.traverseForward(CodeFoldingSideBar.java:332) at org.netbeans.editor.CodeFoldingSideBar.getPaintInfo(CodeFoldingSideBar.java:299)
Created attachment 94348 [details] stacktrace
Created attachment 97205 [details] stacktrace http://smetiste.czech.sun.com/builds/netbeans/6.9/beta/2010-04-12_22-01-23-javafx/ -install, start IDE -create new JavaFX Application and exception appears
Created attachment 97207 [details] stacktrace scrolled JavaFX source in editor while scanning projects was in progress
Product Version: NetBeans IDE 6.9 Beta (Build 201004122201) Java: 1.6.0_18; Java HotSpot(TM) Client VM 16.0-b13 System: SunOS version 5.11 running on x86; UTF-8; en_US (nb) The exception is endless, blocking source editor functionality . Raising to P1.
Is it affected by the view hierarchy? Can you get rid of it by disabling the line wrap by -J-Dorg.netbeans.editor.linewrap=false ? But it looks like the "artificial end of line at the last line" problem from the first glance at the exception text.
Created attachment 97246 [details] stacktrace
Created attachment 97247 [details] stacktrace
> Can you get rid of it by disabling the line wrap by > -J-Dorg.netbeans.editor.linewrap=false ? No. Thrown after typing any character or just displaying an editor buffer; makes IDE unusable. Need a hotfix ASAP (parented to a cset in main-silver so it can be merged into team repos).
(In reply to comment #8) > > Can you get rid of it by disabling the line wrap by > > -J-Dorg.netbeans.editor.linewrap=false ? > > No. Correct. This DOES happen with -J-Dorg.netbeans.editor.linewrap=false, but does NOT happen with -J-Dorg.netbeans.editor.linewrap=true. Therefore, this mainly affects 6.9beta where -J-D...linewrap=false is the default option.
(In reply to comment #9) > this mainly affects 6.9beta where -J-D...linewrap=false is the default option Or anyone else using dev builds who wants to disable line wrap mode to avoid other serious bugs.
(In reply to comment #8) > Need a hotfix ASAP (parented to a cset in main-silver Probably best parented to release69_base if not earlier, for easy merging. (I tried to use 'hg bisect' to find the cause, but I could not reproduce it when I actually wanted to, as is typical.)
(In reply to comment #11) > (I tried to use 'hg bisect' to find the cause, but I could not reproduce it > when I actually wanted to, as is typical.) IMO it's caused by http://hg.netbeans.org/main-silver/rev/4d62d39b41e7, which was ported to 6.9beta branch as http://hg.netbeans.org/release69_beta/rev/d910d8c94b8e. Btw. we should add o.n.e.Utilities to exception reporter's list of innocent classes, because these failures have nothing to do with the original problem that this bug was filed for.
(In reply to comment #12) >> I tried to use 'hg bisect' to find the cause, but I could not reproduce it > > IMO it's caused by #4d62d39b41e7 No, I knew about this and so passed both system properties to make sure line wrap was disabled in each version.
> DOES happen with -J-Dorg.netbeans.editor.linewrap=false, > does NOT happen with -J-Dorg.netbeans.editor.linewrap=true. Matches what I'm seeing. SCROLLING causes the problem when near the END OF FILE. Later stacktraces have a different signature, Highlight code: javax.swing.text.BadLocationException: Invalid offset=336 not within <0, 335> ... at org.netbeans.modules.editor.url.HighlightURLs.getHighlights(HighlightURLs.java:96) at org.netbeans.modules.editor.lib2.highlighting.ProxyHighlightsContainer.getHighlights(ProxyHighlightsContainer.java:121) at org.netbeans.modules.editor.lib.drawing.HighlightingDrawLayer.processOffset(HighlightingDrawLayer.java:627) ... Product Version: NetBeans IDE Dev (Build 201004131450) Java: 1.6.0_18; Java HotSpot(TM) Client VM 16.0-b13 System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb) Userdir: C:\Documents and Settings\erra\.netbeans\dev
http://hg.netbeans.org/jet-main/rev/14c2cbfc781f - parented to release69_beta_base.
*** Bug 184101 has been marked as a duplicate of this bug. ***
Ported to release69_beta clone as: http://hg.netbeans.org/release69_beta/rev/d6f74efda521 http://hg.netbeans.org/release69_beta/rev/c4c9d78f739b
(In reply to comment #17) > Ported to release69_beta clone as: > http://hg.netbeans.org/release69_beta/rev/d6f74efda521 BTW the whole point of parenting 14c2cbfc781f to release69_beta_base is so you can pull the changeset directly without using transplant. But never mind.
*** Bug 184390 has been marked as a duplicate of this bug. ***
Created attachment 97676 [details] stacktrace
Apparently, this bug is not fixed properly as it has happened in NB 7.0 M2. See http://statistics.netbeans.org/exceptions/detail.do?id=165466, duplicate 432275. This happened in NB 7.0 M2, JDK 6u22 64-bit, while editing source code of a plain Java class. I think it happened just after manual invocation of code-completion. Or maybe this bug is fixed in NB 6.9 but somehow the fix did not get to 7.0?
Milo, can you please have a look? Thanks a lot.
The doc.getLength() + 1 is now a valid offset for the particular methods in org.netbeans.editor.Utilities. http://hg.netbeans.org/jet-main/rev/9502a92fe28f
Integrated into 'main-golden', will be available in build *201011240001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/9502a92fe28f User: Miloslav Metelka <mmetelka@netbeans.org> Log: #180980 - javax.swing.text.BadLocationException: Invalid offset=1889 not within <0, 1888> - allow methods in o.n.editor.Utilities to use doc.getLength()+1 offset.