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.
I was playing with a Java file with a form. I repeatedly toggled between the form editor and the source code editor. After several rounds of switching, I found that there is no syntax highlight in the source code editor. So I tried the usual "get out, get back" steps - I closed the file, then went to File > Recent File... and selected the topmost file. What I got was that the IDE froze for at least several minutes (it is still frozen now), eating approximately "160 %" of CPU cycles according to program "top" (this is a quad-core CPU, full usage is reported as 400 %). I will attach several thread-dumps. -- NetBeans 6.8 dev. build 090712 JDK 6u14, 64-bit, server VM Linux (Debian Lenny), 64-bit, Intel CPU
Created attachment 84629 [details] full thread-dump taken by jstack
Created attachment 84632 [details] full thread-dump 2
Created attachment 84633 [details] full thread-dump 3
Created attachment 84634 [details] full thread-dump 4
Created attachment 84635 [details] full thread-dump 5
Yes, there is some indexing task running, but it is stuck (as well as other threads in the dumps) somewhere in org.netbeans.modules.apisupport.project.Evaluator and in filesystems. I'm not sure what exactly was going on in the IDE, but I have already seen similar stacktraces from other people. Strange thing is that this apparently happens only under certain circumstances and nobody has been able to provide reliable steps for reproducing this so far. Maybe somebody knowledgeable in apisupport projects could guess the reason. From the indexing side we use SourceForBinaryQuery for locating sources for binary classpath roots, the SFBQ I guess is somehow supplied by projects, which I guess is when some ant properties evaluation is needed... I'm also CCing Tomas and Jesse who might have some useful ideas or suggestions. Thanks
Root cause is similar as in issue #165862: filesystem schedules a lot of tasks, which are retrieving its stack trace in constructor, which is slow. Plus all this is synchronized on static variable, thus all threads trying to load projects are blocked. Fixing this particular case is simple, just create RP in o.o.fs.FCLSupport with enableStackTraces=false, but I guess such issues will show up now and then after http://hg.netbeans.org/main/rev/b8dcce795dc4, maybe there should be more general fix. Jesse has suggested to somehow adaptively disable stack traces when there are many tasks scheduled.
Right, I still disagree with the fix of issue #165862. (Again, b8dcce795dc4 is not the origin; you mean 3b30abd0e2b6.)
So, what do you recommend? Should I disable stack traces in o.o.fs.FCLSupport or should I wait until automatic turning off is implemented in RequestProcessor as suggested in issue 165862 desc9 [JG01]?
I disabled stack traces in RequestProcessor in FCLSupport. core-main #50edf4a73722
Integrated into 'main-golden', will be available in build *200907290201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/50edf4a73722 User: Jiri Skrivanek <jskrivanek@netbeans.org> Log: #168450 - Disable stack traces in our RequestProcessor for performance reasons.