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.
Under some conditions which I have not been able to identify, compilable classes in my project (which have not recently been edited, and which have up-to-date target/classes/**/*.class) suddenly get an error badge on the editor tab and on the file node. The status box in the editor remains green or yellow, there are no error annotations, and Ctrl-Alt-PERIOD shows only warnings (if anything). It is generally the same classes in a given project that suffer from this, but there is nothing obviously distinguishing these classes from others in the project. When the problem occurs, the only way to get the badges to disappear is to open each of the files in turn, make some trivial change (such as typing SPACE DELETE), and save it; then the error badge goes away on that file, and if repeated I can get the error badges to go away on the package and project nodes. A few hours later the problem will suddenly reappear. Nothing is shown in the log file during this time. Filing in 20140430-6a41887cb2db but observed for a long time. Editor » Hints » Java » Dependency Scanning is disabled but Compile on Save is enabled. Groovy plugin installed but no Groovy sources in use in the open project. The project has some generated sources (produced by a Maven plugin); I think the affected classes were all referring to generated classes, but target/generated-sources/* has not been deleted recently, and other unaffected classes were also referring to generated classes. Surely it should be an invariant that a open editor tab shows an error badge iff there is at least one error annotation in the pane? It would seem simple for the IDE to check this condition and, if violated, dump some diagnostics to the log.
I should note that frequently when I am editing a class and introduce a genuine compilation error, the IDE clearly recognizes that one exists—the editor tab gets an error badge and if I try to run in CoS mode anyway, I get “uncompilable source code” errors—yet no error annotation is displayed. In this case Ctrl-Alt-PERIOD does work to jump to the erroneous line and display the error in the status bar (though I have to first move past any preëxisting warnings, which *are* displayed as annotations), and if I correct the error the badge goes away. This has been happening to me for some time now in various dev builds. So there may be something fundamentally broken in annotation display.
I may need to retract what I said about the log not showing anything—it seems that my log file had been overwritten by another copy of NetBeans starting up before I killed it, so I lack a copy of the real log file. (Normally I use a script running ‘…/bin/netbeans --open file’ to open files from a shell and this works fine. From time to time it fails to find the running copy of the IDE and tries to start a new one in the same userdir, which I have to kill.) I am running with -Dorg.netbeans.modules.java.source.tasklist.IncorrectErrorBadges.disable=true since leaving it on caused performance problems.
I have removed -Dorg.netbeans.modules.java.source.tasklist.IncorrectErrorBadges.disable=true and now error badge correction seems to be triggered under these circumstances, and sometimes corrects the badges; sometimes it does not, and the correction task runs itself again, working the second time. (I used to often see the task run over and over without ever succeeding, which is why I disabled it.) At any rate, even if the correction task is disabled, the IDE should just remove the badge (without recompiling anything) if the editor window shows no errors. Right?
Have to turn IncorrectErrorBadges back off. Otherwise I get endless “corrections” on (for example) PluginManager.java which do not correct anything: WARNING [org.netbeans.modules.java.source.tasklist.IncorrectErrorBadges]: Incorrect error badges detected, file=/space/src/jenkinsci/jenkins/core/src/main/java/hudson/PluginManager.java. WARNING [org.netbeans.modules.java.source.tasklist.IncorrectErrorBadges]: Going to recompute root=/space/src/jenkinsci/jenkins/core/src/main/java, files in error=[file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/Functions.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/PluginManager.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/ProxyConfiguration.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/jenkins/mvn/GlobalSettingsProvider.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/jenkins/security/ConfidentialStore.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/jenkins/model/Jenkins.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/jenkins/slaves/JnlpSlaveAgentProtocol2.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/tools/ToolLocationNodeProperty.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/tools/JDKInstaller.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/tools/ToolInstallation.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/security/BasicAuthenticationFilter.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/security/HudsonPrivateSecurityRealm.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/security/SecurityRealm.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/security/ACL.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/lifecycle/Lifecycle.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/lifecycle/WindowsInstallerLink.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/views/ListViewColumn.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/diagnosis/HudsonHomeDiskUsageChecker.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/util/XStream2.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/logging/LogRecorder.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/model/AbstractCIBase.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/model/AbstractProject.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/model/Computer.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/model/JobParameterDefinition.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/model/View.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/model/AbstractBuild.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/model/Node.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/model/Run.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/cli/CLICommand.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/scm/ChangeLogSet.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/scm/SCMDescriptor.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/search/CollectionSearchIndex.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/search/SearchIndexBuilder.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/scheduler/CronTab.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/jenkins/model/lazy/AbstractLazyLoadRunMap.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/security/csrf/CrumbFilter.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/tasks/junit/PackageResult.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/tasks/_maven/MavenConsoleAnnotator.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/util/jna/Advapi32.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/util/io/ArchiverFactory.java, file:/space/src/jenkinsci/jenkins/core/src/main/java/hudson/util/spring/BeanBuilder.java]. (The part after file:/space/src/ is the full GitHub org, repo, and path.)
I was successful *once* in reproducing some similar behaviour. The root cause was (IMHO) a failure of an annotation processor: [/home/sdedic/NetBeansProjects/jenkins/core/src/main/java/hudson/console/AnnotatedLargeText.java@aa43e8f3:3e4cfb99, -1, javax.annotation.processing.FilerException: Attempt to reopen a file for path exposed.stapler-beans at com.sun.tools.javac.processing.JavacFiler.checkFileReopening(JavacFiler.java:581) at com.sun.tools.javac.processing.JavacFiler.getResource(JavacFiler.java:529) at org.kohsuke.stapler.jsr269.AbstractProcessorImpl.getResource(AbstractProcessorImpl.java:77) at org.kohsuke.stapler.jsr269.ExportedBeanAnnotationProcessor.scanExisting(ExportedBeanAnnotationProcessor.java:137) It may be possible that such errors will remain recorded until the file is opened and rescanned as a single file; no dependency tracking helps in this situation.
It seems that the ExportedBeanAnnotationProcessor attempts to generate the stapler output file incrementally. It is not permitted to write again to a file which has been already written as implemented in the Processor; if the Processor needs to collect information from multiple rounds of processing, it should flush and create the output file when isProcessingOver == true. I am not (yet) sure whether reading-after-creation through Filer is permitted, but I would guess not (given the above limitation) - the Filer has to buffer the data anyway, so it should not read the file. Please correct the annotation processor, it should eliminate the endless refreshes of the error badges.
Where did this stack trace appear? Was it in the log file? Easy enough to correct processors once you know that they have a problem.
https://github.com/stapler/stapler/commit/6aa05d3299e04e40bc9f6f0564a83dafb9fc2c64 ought to fix this I think, though there are other faulty processors out there so better user-level diagnostics would be in order. (AbstractServiceProviderProcessor and LayerGeneratingProcessor in NB look to already be correct.)
Still getting this error badge on occasion, appearing at line 1 in a file using the processor. The stack trace is from ExportedBeanAnnotationProcessor:41, which in the new code is calling createResource only when roundEnv.processingOver(). Adding -Xlint:processing to compiler args has no apparent effect. JavacFiler seems to allow any number of reads, followed by one write, after which no operations are permitted. But the fixed version of this processor should be doing just that. Perhaps two copies of the processor are being run in one processing environment? That is the only thing I can think of which would account for the problem. Is there some way to get detailed logging on which processors are being run in each round? It would also be helpful if fileObjectHistory were made into a Map<FileObject,Throwable> recording the stack trace of the first createResource (or createSourceFile or createClassFile) call, where the Throwable.message would record the System.identityHashCode of the Processor making the call (if that information is available here); the FilerException.cause would then record this original stack trace.
I added some System.err.println’s to the annotation processor, but of course after doing this I can no longer find any file with the FilerException (though there are tons of other spurious error badges which quietly disappear when I resave the file).
I did not notice that the first time there was some background scanning after adding the logging to the processor (which involved switching to the snapshot dependency on the project defining the processor), I saw a long block of dozens of repeated cases where the processor was called with processingOver=false then with processingOver=true; the same processor instance and processing environment instance (identified by hash code) was used in each case. This seems suspicious, since even if you are scanning a bunch of files at once I would expect just one call to process per processor per round; or if each file is scanned separately, I would expect a fresh processor and environment for each file. Thereafter each file edit triggered the expected one pair of calls, to a fresh processor and env each time. So perhaps the problem is that during whole-classpath scanning a single processor is repeatedly put through all its rounds, without close() being called on the environment between phases. This would produce the observed behavior of a FilerException being thrown from a processor which (like ExportedBeanAnnotationProcessor) generates a resource file with a fixed name (or at least a computed name sometimes shared among several annotated files). In that case I would expect to see a similar problem in NB module code using LayerGeneratingProcessor and the like. I currently have Tools » Options » Editor » Hints » Java » Dependency Scanning disabled, in case that matters, and am running a dev build from Sep 19.
Still valid ?