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.
Product Version: NetBeans IDE Dev (Build 200806260103) Java: 1.6.0_06; Java HotSpot(TM) Client VM 10.0-b22 System: Linux version 2.6.24-19-generic running on i386; UTF-8; en_US (nb) Userdir: /home/tester/.netbeans/dev Step to reproduce: -I perform full installation with Apache Tomcat server. -Create a sample NB project Paint Application - File | New Project | Samples | NetBeans Plug-in Modules | Paint Application - start CPU profiling I've got : java.io.IOException: cannot read directory org.apache.lucene.store.FSDirectory@/home/tester/.netbeans/dev/var/cache/index/0.8/s17/refs: list() returned null at org.apache.lucene.index.SegmentInfos.getCurrentSegmentGeneration(SegmentInfos.java:111) at org.apache.lucene.index.IndexReader.indexExists(IndexReader.java:418) at org.netbeans.modules.java.source.usages.LuceneIndex.isValid(LuceneIndex.java:697) at org.netbeans.modules.java.source.usages.LuceneIndex.getUsagesFQN(LuceneIndex.java:123) at org.netbeans.modules.java.source.usages.PersistentClassIndex.getUsagesFQN(PersistentClassIndex.java:296) at org.netbeans.modules.java.source.usages.PersistentClassIndex.usages(PersistentClassIndex.java:284) at org.netbeans.modules.java.source.usages.PersistentClassIndex.access$000(PersistentClassIndex.java:70) at org.netbeans.modules.java.source.usages.PersistentClassIndex$1.run(PersistentClassIndex.java:139) at org.netbeans.modules.java.source.usages.PersistentClassIndex$1.run(PersistentClassIndex.java:138) at org.netbeans.modules.java.source.usages.ClassIndexManager.readLock(ClassIndexManager.java:134) at org.netbeans.modules.java.source.usages.PersistentClassIndex.search(PersistentClassIndex.java:137) at org.netbeans.api.java.source.ClassIndex.getElements(ClassIndex.java:276) at org.netbeans.modules.profiler.AbstractProjectTypeProfiler.addImplementorMethods(AbstractProjectTypeProfiler.java:303) at org.netbeans.modules.profiler.AbstractProjectTypeProfiler.doAddInterfaceMarker(AbstractProjectTypeProfiler.java:381) at org.netbeans.modules.profiler.AbstractProjectTypeProfiler.access$000(AbstractProjectTypeProfiler.java:87) at org.netbeans.modules.profiler.AbstractProjectTypeProfiler$1.run(AbstractProjectTypeProfiler.java:233) at org.netbeans.modules.profiler.AbstractProjectTypeProfiler$1.run(AbstractProjectTypeProfiler.java:231) at org.netbeans.api.java.source.JavaSource.runUserActionTask(JavaSource.java:666) at org.netbeans.modules.profiler.AbstractProjectTypeProfiler.addInterfaceMarker(AbstractProjectTypeProfiler.java:227) at org.netbeans.modules.profiler.nbmodule.NbModuleProjectTypeProfiler.setupMarks(NbModuleProjectTypeProfiler.java:289) at org.netbeans.modules.profiler.nbmodule.NbModuleProjectTypeProfiler.getMethodMarker(NbModuleProjectTypeProfiler.java:117) at org.netbeans.modules.profiler.NetBeansProfiler.setupDispatcher(NetBeansProfiler.java:2109) at org.netbeans.modules.profiler.NetBeansProfiler.prepareInstrumentation(NetBeansProfiler.java:1634) at org.netbeans.modules.profiler.NetBeansProfiler$3.doInBackground(NetBeansProfiler.java:1111) at org.netbeans.lib.profiler.ui.SwingWorker$2.run(SwingWorker.java:113) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:561) [catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:986)
Created attachment 63496 [details] Message.log
Similar behaviour for Memory profiling
Created attachment 63497 [details] Memory profiling message.log
Changed OS -Linux. Ireproduced it on Ubuntu 8.04
Jirko, can you reproduce it?
rashid, is /home/tester/.netbeans/dev/var/cache/index/0.8/s17/refs accessible?
There are not folder /home/tester/.netbeans/dev/var/cache/index/0.8/s17 on my computer. The last one in /home/tester/.netbeans/dev/var/cache/index/0.8 directory is s12.
Seems like a duplicate of issue #129931 - too many opened files.
Doesn't seem to be caused by the profiler, it just uses ClassIndex.getElements(ElementHandle, Set, Set) API call which shouldn't throw such exception. Reassigning.
The root cause, IMO, is that there are too many opened files - see the first attached messages.log (and issue #129931). I doubt there is anything reasonable that the Java infra could do about this (even if this exception would be suppressed, it is not possible to return correct results, and other parts of the IDE would still suffer from not enough file descriptors. Moreover, this would be only masquerading the real problem in this case.)
BTW: given that issue #129931 was waived for NB6.1, I do not think this should be considered a 6.5M1 stopper.
Sorry for not reading the log files carefully - you're right, too many open files may have been the root cause of the problem. Marking as duplicate of Issue 129931, increasing the limit of open files should work as a workaround. Anyway, AFAIK the profiler cannot check or control current open files usage, it just uses public API which doesn't describe any dependency on number of opened files. And since any other code could experience exactly the same problem using this API call, I don't think it's a profiler bug. If the java infrastructure uses large queries which could cause such problems, it should somehow solve it or at least mention it in API docs and provide sample solutions how to avoid or process it. Also, are sure that trying to access a non-existing folder which throws an IOException in org.apache.lucene library is the same case as accessing an existing file which is just not available because too many files are already open? Just an idea not to mask some other problem... *** This issue has been marked as a duplicate of 129931 ***
I have added an analysis to issue #129931. >Anyway, AFAIK the profiler cannot check or control current open files usage, it just uses public API which doesn't >describe any dependency on number of opened files. And since any other code could experience exactly the same problem >using this API call, I don't think it's a profiler bug. Not sure which API call you mean - the profiler seems to be trying to keep 978 files open at the same time (see my comment in issue #129331). I do not think this is reasonable. >If the java infrastructure uses large queries which could cause such problems, it should somehow solve it or at least >mention it in API docs and provide sample solutions how to avoid or process it. It is true that the Java infra is keeping quite a few files open (~288 in my development IDE), but I am not aware this would be causing any problems in any case, except profiling. >Also, are sure that trying to access a non-existing folder which throws an IOException in org.apache.lucene library is >the same case as accessing an existing file which is just not available because too many files are already open? Just >an idea not to mask some other problem... Likely, the cache directory was not created due to the Too many opened files problem. We could throw an exception sooner, but this would only help to identify the problem sooner, not to solve it, IMO.
Oops, the second reference to an issue should be: issue #129931.