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.
Summary: | Error annotations on packages and projects get stuck | ||
---|---|---|---|
Product: | java | Reporter: | _ tboudreau <tboudreau> |
Component: | Source | Assignee: | Jan Lahoda <jlahoda> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | devon_c_miller, jglick, matthies, quintesse, zdro |
Priority: | P2 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 137568, 182530 | ||
Bug Blocks: | 121950 | ||
Attachments: |
Screen shot
Gzipped tar of var/cache/index/0.4/s3[0-5] |
Description
_ tboudreau
2007-05-23 22:20:52 UTC
Created attachment 42709 [details]
Screen shot
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. *** Issue 103531 has been marked as a duplicate of this issue. *** +1 - I see this happening on normal packages where there are no errors within, and everything builds without error or warning. *** Issue 117003 has been marked as a duplicate of this issue. *** *** Issue 117274 has been marked as a duplicate of this issue. *** *** Issue 117299 has been marked as a duplicate of this issue. *** *** Issue 117856 has been marked as a duplicate of this issue. *** *** Issue 116295 has been marked as a duplicate of this issue. *** *** Issue 116680 has been marked as a duplicate of this issue. *** *** Issue 117981 has been marked as a duplicate of this issue. *** *** Issue 118309 has been marked as a duplicate of this issue. *** Given the number of duplicates, should this be a P2? 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. *** Issue 118351 has been marked as a duplicate of this issue. *** > 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)
*** Issue 118468 has been marked as a duplicate of this issue. *** *** Issue 118467 has been marked as a duplicate of this issue. *** *** Issue 118469 has been marked as a duplicate of this issue. *** 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 Created attachment 50694 [details]
Gzipped tar of var/cache/index/0.4/s3[0-5]
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.
Thanks for the use case. I am working on a fix, should not be very difficult. 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 *** Issue 118634 has been marked as a duplicate of this issue. *** *** Issue 118735 has been marked as a duplicate of this issue. *** 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. Sorry, forgot to mention that the use case I added on 11/26 applies to 6.0rc2. 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. Please set target milestone properly. Thanks. *** Issue 126180 has been marked as a duplicate of this issue. *** 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. 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). 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. 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. 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... 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. 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. 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. 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 ;) ). *** Issue 129907 has been marked as a duplicate of this issue. *** 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 *** Issue 129228 has been marked as a duplicate of this issue. *** *** Issue 131126 has been marked as a duplicate of this issue. *** *** Issue 131983 has been marked as a duplicate of this issue. *** *** Issue 109177 has been marked as a duplicate of this issue. *** *** Issue 124335 has been marked as a duplicate of this issue. *** *** Issue 124335 has been marked as a duplicate of this issue. *** |