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.
061128. Do not know how to reproduce. Was editing a .java file, had attempted code completion which somehow got corrupted, then suddenly exceptions started being thrown. After I madly hit Escape and arrow keys several times they stopped.
Created attachment 36332 [details] Stack trace
Thrown over and over and interferes with editing. Reproduced in another file by invoking CC on Exception.attachAnnotation and then trying to replace the guessed parameters with real values. Also found another stack trace in there.
Created attachment 36334 [details] AssertionError from TextLexerInputOperation.<init>
Happening repeatedly, on nearly every file I edit. Makes this build unusable. I am going back to an older dev build for now.
Seems it also happens frequently in 061122. Will check to see if it is userdir-specific.
Does not seem to happen with a fresh user dir. No idea what could have happened to my user dir today that would suddenly trigger this. I presume that some data structure is being corrupted before the code mentioned in the stack traces runs. Let me know if you need me to try harder to find out what is triggering the bug.
The lineAnnos found for the particular annotation is not present in the lineAnnotationsArray in the Annotations.java. I've done just a quick fix because the storage needs a rewrite anyway (we need to eliminate use of the DrawMark-s and use a binary-searchable annotations storage). Regarding the exc in TextLexerInputOperation it might happen if there would be an embedding and its initial and end skip lengths would be higher than the branch token length. But it's probably not the case here. Anyway I will add a check for that. Fix in Annotations: Checking in Annotations.java; /cvs/editor/libsrc/org/netbeans/editor/Annotations.java,v <-- Annotations.java new revision: 1.29; previous revision: 1.28
Well I am no longer getting these exceptions in 061129. However now it seems that if there are errors in a source file, they are displayed using a wavy red underline at the actual point of occurrence, but there is no mark in the gutter, nor in the scrollbar nor summary. (Warnings are correctly displayed!) Nor can you get a tooltip with the text of the error (due to another outstanding Retouche regression).
Turns out that I had an empty $userdir/config/Editors/AnnotationTypes/org-netbeans-spi-java-parser_annotation_err.xml Not really sure how that happened (dated to Nov 24), but when I remove that then error annotations are back to normal. So what editor code gets a fatal parser error but does not report it in the log file? AnnotationTypeProcessor *looks* like it would report a fatal parse error, but apparently it doesn't. ATP.Handler fails to override error(...) or warning(...) methods to warn about the problem, which it probably should, but I think an empty document would call fatalError(...).
It looks like ATP.parse() is using a non-validating parser, so it probably does not catch many errors. I don't see why we should be using non-validating parser, we've got DTDs that are a public contract for annotation providers and we should use them to check registered files.
moving opened issues from TM <= 6.1 to TM=Dev
Hi Jesse, is this still an issue in the latest dev builds? I believe the parsing implementation has changed a bit since this issue was reported...
I don't think I saw this after deleting the empty (~ corrupt) org-netbeans-spi-java-parser_annotation_err.xml. Not sure what this has to do with any parsing implementation. Seems rather related to annotation loading code: AnnotationTypeProcessor.
Not sure it have sense to keep not reproducible any more issue opened. Feel free to reopen if have opposite opinion. Also don't see anything similar to the issue in 090409.
I wouldn't expect you to see it unless you had a corrupted ann desc file. As vstejskal said (Mar 20 2007), we have a DTD for these files, so we should parse them according to it. This would improve robustness.
ok, it's always good to have system stable for minor corruptions, but don't see it as a big issue in case if corruption wasn't produced by nb itself. Do you have expected scenario for use case if editor found config as corrupted?
Should log something to messages.log indicating the file which was corrupt, and skip over it. Also possible to delete the corrupt file in the userdir, though this is a little trickier since FileObject.delete will create a *_hidden mask file if the file was originally defined in an XML layer; what you want is Object rW = fo.getAttribute("removeWritables"); if (rw instanceof Callable) { ((Callable<?>) rw).call(); } See: http://bits.netbeans.org/dev/javadoc/org-openide-modules/overview-summary.html#property-RevertFSModifications
Implementing comment #17 is now easier; just: fo.revert()
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss