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.
Sometimes, project switch works OK, sometimes it takes VERY long (while NB consumes 100% CPU time) but completes eventually and sometimes after taking long, one of the two runide.exe (the small one) vanishes and NB never comes back, leaving no choice but to force NB to end with the task manager. This is a very nasty problem. I have attached a thread dump from the third case. Can someone from the developers please have a short look at it? This is no one-PC-problem, it happens on many machines here.
Created attachment 7986 [details] full thread dump
I am not sure what happens, but there are several threads spwaned from java parser and cvs command execution which seems to wait for something, but I can't see for what :-\. Tomas, Martin could you look at it please.
I can confirm this happens also on my Linux box... very annoying.
Even WHEN it works OK (most of the time), it's still never really fast.
VCS threads are O.K. "VCS Commands Execution Thread-*" wait for some work (VCS commands to execute), "VCS Command Executor Starter Loop" waits for VCS commands to distribute into "VCS Commands Execution Thread-*", "External Command Output Grabber Processor" waits for output from VCS commands to process and "VCS Cache Poll Request Processor" waits for ReferenceQueue to clean. These threads waits for work and do not block other threads.
Yes, it's annoying, and if fixed, it will be a candidate for 3.4.1, but I can't afford it blocking # 28441 (no QA, no testcase, sometimes hangs, sometimes works, etc...) Sincere, Maxym Mykhalchuk
a hint on a possible resolution: i've noticed that if you garbage-collect the IDE, it doesn't hang. hope this helps!
Hi. This issue is marked as 3.4.1_CANDIDATE. It means that it should be integrated into release341 one branch. The plan at http://www.netbeans.org/devhome/docs/releases/34/index.html expected beta1 to be produced on Dec01. That did not happen due to a lot of outstanding not integrated candidates like this one. Would it be possible to spend few minutes by backporting this fix? Thank you in advance.
I am sorry to all, but this issue has not been fixed yet and that's why it is not integrated in release341 branch and I doubt we are able to fix it for Nb 3.4.1, sorry again. What's the process now, should I remove the 3.4.1_CANDIDATE keyword?
Removing keyword is the right action I guess. Maxym should know for sure...
While this happened (rarely) with 3.4, I'm sure we cannot solve the unsolvable and commit nothing. I hope it vanish with new projects.
Created attachment 8924 [details] full thread dump
I've attached full thread dump from very similar deadlock, please could you look at it? Happened during regular usage of nb34 build.
The deadlock is in javacvs filesystem, see issue #31206. The first FTD doesn't show any deadlock (at least as I can see). If the system is busy during projects switch it is mainly because the change of project layer in default file system which fires zillions of events from the DFS. All other parts of system (e.g. winsys, automount, etc.) listen and refresh which can take some time. This shouldn't happen with new projects any more because there will be no changes in DFS layers.
Verified.