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.

Bug 90220 - Poor recovery from corrupted annotation descriptor file
Summary: Poor recovery from corrupted annotation descriptor file
Alias: None
Product: editor
Classification: Unclassified
Component: Hints & Annotations (show other bugs)
Version: 6.x
Hardware: All All
: P4 blocker (vote)
Assignee: Milutin Kristofic
Depends on: 162526
  Show dependency tree
Reported: 2006-11-28 19:45 UTC by Jesse Glick
Modified: 2016-07-07 07:28 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Stack trace (28.73 KB, text/plain)
2006-11-28 19:45 UTC, Jesse Glick
AssertionError from TextLexerInputOperation.<init> (3.19 KB, text/plain)
2006-11-28 20:11 UTC, Jesse Glick

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2006-11-28 19:45:20 UTC
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.
Comment 1 Jesse Glick 2006-11-28 19:45:53 UTC
Created attachment 36332 [details]
Stack trace
Comment 2 Jesse Glick 2006-11-28 20:10:25 UTC
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.
Comment 3 Jesse Glick 2006-11-28 20:11:05 UTC
Created attachment 36334 [details]
AssertionError from TextLexerInputOperation.<init>
Comment 4 Jesse Glick 2006-11-28 22:57:40 UTC
Happening repeatedly, on nearly every file I edit. Makes this build unusable. I
am going back to an older dev build for now.
Comment 5 Jesse Glick 2006-11-28 23:09:45 UTC
Seems it also happens frequently in 061122. Will check to see if it is
Comment 6 Jesse Glick 2006-11-28 23:44:18 UTC
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.
Comment 7 Miloslav Metelka 2006-11-29 09:45:09 UTC
The lineAnnos found for the particular annotation is not present in the
lineAnnotationsArray in the 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;
/cvs/editor/libsrc/org/netbeans/editor/,v  <--
new revision: 1.29; previous revision: 1.28
Comment 8 Jesse Glick 2006-11-29 21:31:53 UTC
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).
Comment 9 Jesse Glick 2006-12-01 02:20:59 UTC
Turns out that I had an empty


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(...).
Comment 10 Vitezslav Stejskal 2007-03-20 02:10:01 UTC
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.
Comment 11 Jiri Prox 2008-04-11 00:45:40 UTC
moving opened issues from TM <= 6.1 to TM=Dev
Comment 12 Petr Dvorak 2009-02-04 10:59:29 UTC
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...
Comment 13 Jesse Glick 2009-02-04 21:00:57 UTC
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:
Comment 14 Sergey Petrov 2009-04-10 11:35:43 UTC
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.
Comment 15 Jesse Glick 2009-04-10 16:32:38 UTC
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.
Comment 16 Sergey Petrov 2009-04-13 16:37:01 UTC
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?
Comment 17 Jesse Glick 2009-04-13 16:46:13 UTC
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();

Comment 18 Jesse Glick 2011-11-29 11:28:11 UTC
Implementing comment #17 is now easier; just: fo.revert()
Comment 19 Martin Balin 2016-07-07 07:28:35 UTC
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