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.
Build: NetBeans IDE Dev (Build 20120404-f78998a2f857) VM: Java HotSpot(TM) Client VM, 22.1-b02, Java(TM) SE Runtime Environment, 1.7.0_03-b04 OS: Linux User Comments: jglick: Opened WindowsRemoteLauncher.java in hudson-core, trying to figure out why it was marked with an incorrect error badge. (Claims that super declaration of launchChannel does not permit it to throw InterruptedException, which is not true.) Stacktrace: java.lang.ArrayIndexOutOfBoundsException: 8 at org.objectweb.asm.ClassReader.readUnsignedShort(ClassReader.java:0) at org.objectweb.asm.ClassReader.<init>(ClassReader.java:0) at org.objectweb.asm.ClassReader.<init>(ClassReader.java:0) at edu.umd.cs.findbugs.asm.FBClassReader.<init>(FBClassReader.java:35) at edu.umd.cs.findbugs.classfile.engine.asm.ClassReaderAnalysisEngine.analyze(ClassReaderAnalysisEngine.java:47) at edu.umd.cs.findbugs.classfile.engine.asm.ClassReaderAnalysisEngine.analyze(ClassReaderAnalysisEngine.java:34)
Created attachment 117835 [details] stacktrace
Let me split this into three independent parts: 1. incorrect error badge: need steps to reproduce. When I opened the project, I have seen the error as well, but it was cleared after the priming build (which failed anyway, but that is a different story), so possibly the compile CP was not correct before the build. 2. the exception itself is almost surely caused by zero-length .sig file. Again, steps to reproduce are needed 3. FindBugs are run on sig files which were produced for files with errors. This leads to a plethora of false warnings, as the corrected .sig files are missing parts of the code that are beyond the erroneous point. I can easily prevent that when FB are running in the editor: http://hg.netbeans.org/jet-main/rev/cf185ce91de5 but a similar problem also occurs when running in the Source/Inspect... dialog. I can easily disable running on source roots compiled with errors, but I guess there should be a warning shown to the user in this case. Petr, any idea on how such a warning could look like? Thanks.
Integrated into 'main-golden', will be available in build *201204080400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/cf185ce91de5 User: Jan Lahoda <jlahoda@netbeans.org> Log: #210725: do not run FindBugs for files compiled with errors.
(In reply to comment #2) > incorrect error badge: need steps to reproduce. When I opened the project, I > have seen the error as well, but it was cleared after the priming build (which > failed anyway, but that is a different story) Sorry, was not able to reproduce either (on a new user dir and a partly new local repo). > the exception itself is almost surely caused by zero-length .sig file. From looking at ClassReader sources, seems right. Since ClassReader throws no checked (or even documented unchecked) exceptions, I guess FBClassReader should be catching AIOOBE and managing it more gracefully?
What does this have to do with bug #211167?
#211167 dependence added by mistake, removing...
http://hg.netbeans.org/main-silver/rev/00cff6d83353
Integrated into 'main-golden', will be available in build *201205250002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/00cff6d83353 User: Jan Lahoda <jlahoda@netbeans.org> Log: #210725: FindBugs integration reads sig files directly from the caches, need to prevent rewriting the sig files while the analysis runs.
Found case how a classfile with zero length could be created, will attach a test case.
Created attachment 120570 [details] Test case.
Created attachment 129063 [details] stacktrace
This bug already has 5 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=186673
Created attachment 130799 [details] stacktrace
changing owner
Report from old NetBeans version. Due to code changes since it was reported likely not reproducible now. Feel free to reopen if happens in 8.0.2 or 8.1.