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: | Wrong error badge | ||
---|---|---|---|
Product: | java | Reporter: | stefan79 <stefan79> |
Component: | Compiler | Assignee: | Dusan Balek <dbalek> |
Status: | RESOLVED INCOMPLETE | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 7.2 | ||
Hardware: | PC | ||
OS: | Windows 7 | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 215109 | ||
Bug Blocks: | |||
Attachments: |
Log-File.
Logfile (yesterday). Screenshot The files from Cache/errors. |
Description
stefan79
2012-06-27 11:17:58 UTC
Created attachment 121440 [details]
Log-File.
Created attachment 121441 [details]
Logfile (yesterday).
Hm, not quite sure from the description what has happened. None of the messages.log contain the full exception stack trace, but that is not likely to be much useful without steps to reproduce. It would be good to know what are the errors that cause the error badges to appear - these can be found e.g. in Windows/Action Items (must enable "Compilation Errors" in the filter, or disable the filter altogether), or in var/cache, in files endings with .err. Thanks. Now I´ve this Problem again. At the folder Cache/errors1/ are 2486 files (creation of the files are between 3 Minutes). I think this happens (often) when I refresh classes, that are at the classpath (local files; no jar-files). Created attachment 121459 [details]
Screenshot
Build is OK, but mostly of the packages are red.
Created attachment 121460 [details]
The files from Cache/errors.
Here is what I tried (finding two other problems along the way) - only on Linux so far: -created a project, added a directory with some .class files on its classpath. -tried to delete the directory (bug: the error badges did not appear "immediately") -tried to copy the class file back. The error badges disappeared almost immediately. Bug: the errors in an opened files did not until a reparse of the file in the editor was forced. -tried to also copy the classfiles again to see if there is a problem with updating What is the exact way how the classfile are updated? How many of them are really changed? If you can reproduce, could you please try running with the following command line options: -J-Dorg.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.level=0 -J-Dorg.netbeans.modules.java.source.indexing.JavaIndex.level=0 -J-Dorg.netbeans.modules.java.source.indexing.JavaBinaryIndexer.level=0 and send us the results? Thanks. This has happened to me as well on the recent daily builds, not yet on RC1. (Windows Vista, Java 7 update 5) It is not common, but it is very frustrating when it happens. I have not found a reproducible test case. Most recently when it has happened on just a file or two, I have been able to make trivial changes to the source files, save them, and then it has corrected itself. If this happens to me again, I will look in my logs and see if I can get more information. Hello guys, In the past (7.1 and 7.0), I was quite often running into this problem with a Maven based project on Windows where some of my Maven module generated Java classes. I got the problem only with those generated classes. I was never able reproduce the problem reliably, but it seems it occurred more often when I was running the "clean" goal from outside Netbeans. The latter seemed to miss the changes sometimes. However the only way to recover then was to shutdown NB and delete the indexed files from the NB cache. With 7.2 this issue seems to have disappeared (at least I did not see it myself anymore). Still waiting for the messages.log with detail logging jmborer, Note that in 7.2 bug 211882 has been fixed (in build 201205050400 specifically), which might be what you saw as it would cause erroneous error badges specifically related to generated Java classes. The root cause was internal compilation not being performed for generated classes, and if a clean is done externally I imagine you'd see it as if changes weren't caught, though I never ran into it with Maven myself. From what I read this bug is about something else. This happened to me again. Unfortunately, do to other factors, the debug switches are not activated on this instance of NB. I will try to reproduce it again later today. What I did was updated my source files (while NB was running) from an external source. We are using AccuRev VCS. I wrote a plugin that provides status checking and stuff for AccuRev in NB, but I do most of my update / commits in a separate program. I noticed that when I did an update today (hundreds of file changed / added) NB immediately started scanning the project. However, the updates were still coming in rapidly even after it started scanning. Only two files in the project had error badges and both of these were incorrect. Instead of using the more draconian measure of deleting my cache directory, I just made intentional errors in those two files, saved them, waited for the scan to complete, and then undid my changes. This fixed them right up. I was wondering if this was a clue as to why it was happening and why it is hard to reproduce. Maybe it has to do with file system changes that netbeans catches, but doesn't realize are continuing causing things to become out of sync. I am using 7.2. |