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 104665 - Error annotations on packages and projects get stuck
Summary: Error annotations on packages and projects get stuck
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Source (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker with 1 vote (vote)
Assignee: Jan Lahoda
URL:
Keywords:
: 103531 109177 116295 116680 117003 117274 117299 117856 117981 118351 118467 118468 118469 118634 118735 126180 129907 131126 131983 (view as bug list)
Depends on: 137568 182530
Blocks: 121950
  Show dependency tree
 
Reported: 2007-05-23 22:20 UTC by _ tboudreau
Modified: 2010-03-22 22:00 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Screen shot (25.15 KB, image/png)
2007-05-23 22:21 UTC, _ tboudreau
Details
Gzipped tar of var/cache/index/0.4/s3[0-5] (14.97 KB, application/octet-stream)
2007-10-11 14:55 UTC, devon_c_miller
Details

Note You need to log in before you can comment on or make changes to this bug.
Description _ tboudreau 2007-05-23 22:20:52 UTC
I've encountered a few instances where error annotations appear on a project or
package or both, and never go away, even when the classes in them are fixed. 
See attached screen shot (notice both that there is nothing wrong with the classes).

Specifically it seems to get confused about unit test packages:  Open, say,
contrib/refactorings.  Open the unit test UsedLocalVariableVisitorTest.  Type
some garbage into the file.

An badge annotation appears on the Unit Test Packages node, and the package node
under it, and the UsedLocalVariableVisitorTest node.  An error badge ALSO
appears on source packages, and the same package under source packages.

Delete the garbage.  The error badges disappear from the unit test packages node
and the package under it.  They do not disappear on the source packages nodes.
Comment 1 _ tboudreau 2007-05-23 22:21:40 UTC
Created attachment 42709 [details]
Screen shot
Comment 2 matthies 2007-07-18 14:07:36 UTC
I've also encountered the issue of "stuck" error annotations a couple of times (not in relation to unit test packages, 
though). The only solution seemed to be to open *all* source files of the package(s) in the editor and trigger source 
code analysis for each one of them (by making some dummy edit and switching forth and back).
Suggestions:

1. Provide a way to clear the analysis cache, since there will always be some remaining possibility that it gets 
corrupted.

2. Resync the analysis upon manual compilation/build (F9/F11 etc.). In particular, no error annotations should be shown 
when a file/package/project has just been successfully compiled.
Comment 3 Tomas Zezula 2007-08-22 15:12:33 UTC
*** Issue 103531 has been marked as a duplicate of this issue. ***
Comment 4 j0ni 2007-09-19 18:38:45 UTC
+1 - I see this happening on normal packages where there are no errors within, and everything builds without error or
warning.
Comment 5 Tomas Zezula 2007-09-28 09:23:24 UTC
*** Issue 117003 has been marked as a duplicate of this issue. ***
Comment 6 Tomas Zezula 2007-10-01 14:55:24 UTC
*** Issue 117274 has been marked as a duplicate of this issue. ***
Comment 7 Jesse Glick 2007-10-01 16:29:38 UTC
*** Issue 117299 has been marked as a duplicate of this issue. ***
Comment 8 Tomas Zezula 2007-10-05 09:24:42 UTC
*** Issue 117856 has been marked as a duplicate of this issue. ***
Comment 9 Tomas Zezula 2007-10-05 10:02:40 UTC
*** Issue 116295 has been marked as a duplicate of this issue. ***
Comment 10 Jiri Prox 2007-10-08 12:35:41 UTC
*** Issue 116680 has been marked as a duplicate of this issue. ***
Comment 11 Jiri Prox 2007-10-08 13:06:13 UTC
*** Issue 117981 has been marked as a duplicate of this issue. ***
Comment 12 Jesse Glick 2007-10-10 01:50:57 UTC
*** Issue 118309 has been marked as a duplicate of this issue. ***
Comment 13 Jesse Glick 2007-10-10 01:52:03 UTC
Given the number of duplicates, should this be a P2?
Comment 14 devon_c_miller 2007-10-10 14:44:40 UTC
I don't know if it's any help, but I have found that shutting down NB and deleting the contents of
{userdir}/var/cache/index makes the problem go away for a while.
Comment 15 Tomas Zezula 2007-10-10 15:34:46 UTC
*** Issue 118351 has been marked as a duplicate of this issue. ***
Comment 16 _ tboudreau 2007-10-11 04:51:35 UTC
> Given the number of duplicates, should this be a P2?

Yes, it should (with apologies to Honza who's bug list it will appear in)
Comment 17 Tomas Zezula 2007-10-11 08:31:33 UTC
*** Issue 118468 has been marked as a duplicate of this issue. ***
Comment 18 Tomas Zezula 2007-10-11 08:31:44 UTC
*** Issue 118467 has been marked as a duplicate of this issue. ***
Comment 19 Tomas Zezula 2007-10-11 08:32:08 UTC
*** Issue 118469 has been marked as a duplicate of this issue. ***
Comment 20 Jan Lahoda 2007-10-11 13:09:21 UTC
Well, in beta 1 there was a problem with refactoring (see issue #115412 and the log below). Also the persistent cache
was made more robust after beta 1 (issue #115996). Currently, the only reproducible problem of stuck error markers on
packages/projects nodes known to me is issue #118309 and issue #118341 (seem to be the same problem, I am working on it.
Should be transient, as opposed to the other problems which were persistent.)

I personally did not see this problem since the above fixes. If it happens in a new build, please:
-pack directory ${nbuser.dir}/var/cache/index/<highest number>/<directory that corresponds to given source root, as
defined in "segments"/ and send it to me.
-try to find a reproducible case - the caches usually are not enough

Thanks.

Checking in test/unit/src/org/netbeans/modules/java/source/usages/RepositoryUpdaterTest.java;
/cvs/java/source/test/unit/src/org/netbeans/modules/java/source/usages/RepositoryUpdaterTest.java,v  <-- 
RepositoryUpdaterTest.java
new revision: 1.4; previous revision: 1.3
done
Checking in src/org/netbeans/modules/java/source/usages/RepositoryUpdater.java;
/cvs/java/source/src/org/netbeans/modules/java/source/usages/RepositoryUpdater.java,v  <--  RepositoryUpdater.java
new revision: 1.88; previous revision: 1.87
done
Comment 21 devon_c_miller 2007-10-11 14:55:24 UTC
Created attachment 50694 [details]
Gzipped tar of var/cache/index/0.4/s3[0-5]
Comment 22 devon_c_miller 2007-10-11 15:05:42 UTC
How to reproduce the state of attachment #50694 [details]:

Create a new project, I used a Java Desktop Application.
Add a new source file (BadClass.java) that contains an error.
The indicator will appear on the package & the project.
Shut down the ide.
Remove the new source
Start the IDE.
Project & package marked with the error indicator, but the package compiles fine.

Observations:
When the IDE is shutdown it persists the error state of the new source file.
Removing a source through the IDE seems to clean everything up, but removing it externally leaves things in an
inconsistent state.
Comment 23 Jan Lahoda 2007-10-11 16:13:32 UTC
Thanks for the use case. I am working on a fix, should not be very difficult.
Comment 24 Jan Lahoda 2007-10-11 21:04:42 UTC
The last usecase should be also fixed now. Thanks.

Checking in RepositoryUpdater.java;
/cvs/java/source/src/org/netbeans/modules/java/source/usages/RepositoryUpdater.java,v  <--  RepositoryUpdater.java
new revision: 1.95; previous revision: 1.94
done
Comment 25 Jiri Prox 2007-10-12 08:34:41 UTC
*** Issue 118634 has been marked as a duplicate of this issue. ***
Comment 26 Jiri Vagner 2007-10-15 09:56:08 UTC
*** Issue 118735 has been marked as a duplicate of this issue. ***
Comment 27 devon_c_miller 2007-11-26 15:12:49 UTC
Here's another Use Case:

We are using a communication library that is generated from files describing the wire protocol.
The usual process here is,
  "make realclean" to remove the java sources,
  cvs update to pull new definitions, then
  "make" to generate the java sources.

I forgot the last step this morning before opening NB6.0rc2.

As a result several of my files are now marked as having errors. (All "Cannot find symbol class Blah".)

After generating the missing sources, my sources continue to display error flags.
Opening my source files show no errors or warnings and they compile clean.

Clean and Build doesn't fix it, neither does Compile Single File, nor closing and reopening NB.

Changing my source (add a space, delete the space, save the file) does clear the flag.
So does running "touch" on my java sources, provided I collapse the project tree so the file is not shown, then
re-expand the tree.
Comment 28 devon_c_miller 2007-11-28 18:02:56 UTC
Sorry, forgot to mention that the use case I added on 11/26 applies to 6.0rc2.
Comment 29 wqtnetbeans 2007-12-07 22:27:54 UTC
The issue of 

http://www.netbeans.org/issues/show_bug.cgi?id=103531

is marked as a duplication of this. 

The problem of 103531 is that the error mark gets stuck with individual Java classes. I checked against 6.0 final, the
problem is not still not resolved.


Comment 30 Jan Becicka 2008-01-31 11:54:55 UTC
Please set target milestone properly. Thanks.
Comment 31 Jan Becicka 2008-02-11 16:20:01 UTC
*** Issue 126180 has been marked as a duplicate of this issue. ***
Comment 32 matthies 2008-02-11 17:57:41 UTC
It appears doubtful to me that this problem (which I still encounter pretty much every day with 6.0/6.1M1) will ever be 
completely solved (and stay solved) at the individual source file level, in particular due to file and classpath 
changes by external tools. The following would help to mitigate the problem much quicker IMO than attempting to fix 
each possible cause of the problem:

- Provide a way to clear the error icons and/or have them recalculated for a given source tree or subtree, e.g. as a 
command in the context menu. This alone would be a great help.

- Provide better synchronization of the the little error/warning indicators at the top of the editor's right edge with 
the error icons in the Projects/Files treeviews. A change of the former should be immediately propagated to the 
treeviews. (Currently it takes opening or changing focus to a different source file in the editor.)

- Have a successful clean build cause any error icons on the source files to disappear.
Comment 33 zdro 2008-02-12 18:14:26 UTC
I would just like to second the comment from matthies.  In particular, the need for a way to manually recalculate the
badges.  Hopefully, any changes would include the Files window; badges are shown there too.

It would be great if it was taken a step further and attached to a larger *refresh* command for the "Projects" and
"Files" windows (or perhaps ANY window).  I currently have no control (that I know of) over when they are updated, and
little indication of what triggers it.  This means that a) I can't get badges to be correct without jumping through
aforementioned hoops, and b) I can't rely on the Files window to reliably show me the contents of my project unless some
unknown amount of time has passed.  I have a project that generates code, and I occasionally have to wait for several
minutes to look at it if I've done a clean build.

Being able to refresh would also make it much easier to reproduce issues like these (and would likely reduce the number
of issues opened in the first place, because there's such an easy workaround).
Comment 34 Jesse Glick 2008-02-13 20:22:37 UTC
A menu item to recalculate badges is just a workaround for buggy logic. The logic needs to be fixed.

To zdro: external changes are automatically picked up whenever you (1) give the NB main window focus (e.g. after having
been working in some command shell), (2) after running any Ant process. Maybe other times as well. If you can _reliably
reproduce_ any situation in which this is not true, please file a separate bug with details.
Comment 35 matthies 2008-02-13 23:05:40 UTC
1) One problem, I believe, is that in a project (or project group with dependent projects) with thousands or tens of 
thousands of source files, the recalulation may take quite long to complete (or at least to reach the "badged" source 
files), and there's no indication that the currently displayed badges are in the process of being re-evaluated.

2) What kind of changes are being picked up? For example when I rebuild one jar project, where another project has the 
jar's target location in its classpath, does the other project detect when the jar has been replaced and recalculate 
the status of all source files that directly or indirectly depend on classes in that jar? (That's one of the situations 
that doesn't work reliably for me.)

3) Opening a source file in the editor does trigger a recalculation of the error status. (That's how I usually clear 
the erroneous error badges.) Surely that is not just to work around broken logic. What we are asking for is to be able 
to trigger that for a whole tree of source files in one go.
Comment 36 _ tboudreau 2008-02-13 23:11:56 UTC
Well, we could badge the badges with a little ... or cloud to show the IDE is reevaluating them.  Or remove previous badges at the start of a new evaluation 
run, but that could be distracting and cause flashing...
Comment 37 Jesse Glick 2008-02-13 23:27:04 UTC
I assume you did not intend to mark this issue FIXED. :-)

#2 - should work, if you can reproduce otherwise please file a bug with details.

#3 - opening the file in the editor probably refreshes status as an unintentional side effect.

I can think of various heuristics for making the underlying bugs be much less severe, without requiring that every
corner case in the internal logic be fixed, and without any user action. For example, if upon opening a file but making
no other changes a badge is cleared, this is a sure sign that some cache is stale - so to be safe, recalculate all
currently visible badges. The performance overhead would only exist when the bug was already manifest. The code in
question could then log some diagnostics to the log file to help resolve the real problem in the future.
Comment 38 matthies 2008-02-14 15:30:48 UTC
Yes, I did not intend to mark this issue as FIXED ;), don't know how that happened.

The heuristics you describe sounds like a resonable alternative to an explicit "recalculate" command.

I'll try to provide reproducable cases, but this is difficult as it usually occurs with CVS updates or refactorings 
affecting a large number of source files, often cross-project.
Comment 39 unr303 2008-03-07 08:06:57 UTC
This very often happens to us most often after restart of ide. Most often when files were updated when ide was off. Here
is diff of cache: open ide - file is marked as error, compile it - compiles ok but is still marked, open it and then
open another file - error hint goes away.
diff -u3 -r cache.1/index/0.8/s144/classes/com/bftcom/property/client/PropertyClient.sig
cache.2/index/0.8/s144/classes/com/bftcom/property/client/PropertyClient.sig
--- cache.1/index/0.8/s144/classes/com/bftcom/property/client/PropertyClient.sig	2008-03-07 09:57:50.706202400 +0300
+++ cache.2/index/0.8/s144/classes/com/bftcom/property/client/PropertyClient.sig	2008-03-07 10:01:08.582930300 +0300
@@ -1,6 +1,6 @@
 GM1;Ncom.bftcom.property.client.PropertyClient;;Lcom.bftcom.fdt.engine.Client;;;
 EM9;Nmain;(M200000000;[Ljava.lang.String;Nargs;)()V;;
-EM4;N<init>;(M200000000;[Ljava.lang.String;Nargs;)()V;;
+EM40000004;N<init>;(M200000000;[Ljava.lang.String;Nargs;)()V;;
 EM4;NinitializeActualityMonitor;()()VLjava.lang.Override;;;;
 EM4;NinitializeCacheManager;()()VLjava.lang.Override;;;;
 EM4;NinitializeLoginManager;()()VLjava.lang.Override;;;;
Only in cache.1/index/0.8/s144/errors/com/bftcom/property/client: PropertyClient.err
Only in cache.1/index/0.8/s144/refs: _22.cfs
Only in cache.2/index/0.8/s144/refs: _24.cfs
Files cache.1/index/0.8/s144/refs/segments.gen and cache.2/index/0.8/s144/refs/segments.gen differ
Only in cache.1/index/0.8/s144/refs: segments_6a
Only in cache.2/index/0.8/s144/refs: segments_6g

This issue isnt critical but is very annoying.
Comment 40 quintesse 2008-03-09 14:50:35 UTC
Can confirm the problem still exists for 6.1 beta as well.

And unfortunately this time delteting the cache folder hasn't worked to fix the problem. So this time I'm stuck not only
with some badges that won't go away, but some java imports the IDE is convinced don't exist (so the code is full of
errors) but the projects compile without any problems.

Just a remark for unr303, I think this _is_ critical, just some badges that get stuck I could live with, but if the code
 editor gets mixed up as well I could just as well use notepad to enter my code (well almost ;) ).
Comment 41 Jan Becicka 2008-03-13 10:10:12 UTC
*** Issue 129907 has been marked as a duplicate of this issue. ***
Comment 42 Jan Lahoda 2008-03-18 16:05:16 UTC
I have recently fixed a couple of problems with the badges:
http://hg.netbeans.org/main?cmd=changeset;node=f1c37a023896
http://hg.netbeans.org/main?cmd=changeset;node=06cd21bdef51

I have also implemented an automatic rebuild broken caches, based on Jesse's heuristics above (see below for more details):
http://hg.netbeans.org/main?cmd=changeset;node=7bef215d6cba

If you have a reproducible case where the files are badged with incorrect error badges, please file them as separate
issues. Thanks.

quintesse, this issue is about stuck error badges (error badges for files, which are parsed fine when opened in the
editor). Please file a new issue with steps to reproduce. Thanks.

The auto-fixer works like this (outline): when an editor for a file is opened or gains a focus, these conditions are
checked:
-is parsed without errors
-is not modified
-is marked with an error badge
-all of these conditions hold after a certain timeout (~2 seconds on UNIX, ~4seconds on Windows)
When all of these conditions are met, the caches for the given source root are completely rebuilt. If any of these
conditions does not hold, nothing is done.

The auto-fixer can be disabled by this cmd line option:
-J-Dorg.netbeans.modules.java.source.tasklist.IncorrectErrorBadges.disable=true
Comment 43 Dusan Balek 2008-03-18 16:47:23 UTC
*** Issue 129228 has been marked as a duplicate of this issue. ***
Comment 44 olhemann 2008-03-26 22:29:12 UTC
*** Issue 131126 has been marked as a duplicate of this issue. ***
Comment 45 Jiri Prox 2008-04-04 09:22:45 UTC
*** Issue 131983 has been marked as a duplicate of this issue. ***
Comment 46 Petr Chytil 2008-09-10 13:11:03 UTC
*** Issue 109177 has been marked as a duplicate of this issue. ***
Comment 47 David Strupl 2009-10-22 14:04:10 UTC
*** Issue 124335 has been marked as a duplicate of this issue. ***
Comment 48 David Strupl 2009-10-22 14:06:44 UTC
*** Issue 124335 has been marked as a duplicate of this issue. ***