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 20120418-1aa84211abae) VM: Java HotSpot(TM) Client VM, 20.6-b01, Java(TM) SE Runtime Environment, 1.6.0_31-b04 OS: Linux User Comments: jglick: Scanning hung in openide.util.lookup/src with 100% CPU after adding a couple basic deps to an NBM project in a suite. Shut down and restarted the IDE and it hung in the same place again. Stacktrace: java.lang.IllegalStateException: getInputStream invoked in AWT at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FileObj.getInputStream(FileObj.java:163) at org.netbeans.modules.apisupport.project.api.Util.getManifest(Util.java:161) at org.netbeans.modules.apisupport.project.NbModuleProject.getManifest(NbModuleProject.java:413) at org.netbeans.modules.apisupport.project.NbModuleProject.getSpecVersion(NbModuleProject.java:500) at org.netbeans.modules.apisupport.project.universe.AbstractEntryWithSources.getSpecificationVersion(AbstractEntryWithSources.java:167) at org.netbeans.modules.apisupport.project.universe.NbPlatform.getDefaultJavadocRoots(NbPlatform.java:597)
Created attachment 118470 [details] stacktrace
(In reply to comment #0) > Stacktrace: Ignore this. Seems reproducible to me in e75fdc1d8219 sources: happened again even after deleting var/cache/index/ and restarting. <module-dependencies> <dependency> <code-name-base>org.netbeans.api.java.classpath</code-name-base> <build-prerequisite/> <compile-dependency/> <run-dependency> <release-version>1</release-version> <specification-version>1.32</specification-version> </run-dependency> </dependency> <dependency> <code-name-base>org.openide.actions</code-name-base> <build-prerequisite/> <compile-dependency/> <run-dependency> <specification-version>6.25</specification-version> </run-dependency> </dependency> </module-dependencies>
Created attachment 118471 [details] Self-sampler
Makes IDE unusable.
I think fixed by 1ac0accbceed.
Yes, Marek already fixed it.
I found the problem almost instantly after pushing the problematic changeset, created a fix but accidentally forgot to commit (ElementsParser change). The change was then joined to the "Iterating html elements: Using SoftReference instead of WeakReference in the cache - the weakly cached blocks were ofter GCed even during one iteration cycle" change and unfortunately pushed next morning. I'm sorry. So do not worry it wasn't fixed by changing the reference type :-)