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.
[ JDK VERSION : J2SE 1.4.2_02 ] When searching by status after updating a CVS file system, (search is for those objects that are NOT Up-to-date), on some occasions, the search never ends and never shows results (it's known that there are files which are not up to date). Attached is a screenshot exhibiting this behavior and the corresponding thread dump.
Created attachment 13609 [details] screen shot
Created attachment 13610 [details] thread dump
Reassigning.
From the thread dump, I guess the problem is with module VCS - reassigning. The suspicious threads are "SearchTask" and "VCS Command Tasks Starter Loop".
The problem is in the "SearchTask" thread. VcsCacheDir.waitToLoad() waits for the cache directory to be loaded, but for some reason it looks like it's never loaded. As a workaround Recursive Refresh can help. Or stop the search and run it again. This problem will likely be solved by the cache redesign (issue #32089).
Neither of these suggestions solve the problem... the only way for the search to succeed is to restart netbeans and hope that it doesn't get into this state before the search completes successfully
I hit this bug today. I searched for modifed files, all files showed up, so I did a Refresh Recursive at the cvs root. Clicked Modify Search, and then OK. That search basically hangs the IDE, so there is no way to stop the search. I did 13 thread dumps and found one thread that was definately looping under a certain stack frame. I'm attaching 2 files, one (SearchHang.txt) is the trimmed stack traces that have just the thread that seems to be stuck, and the other (SearchHangFull.txt) is all 13 dumps.
Created attachment 15018 [details] Trimmed Stack Traces
Created attachment 15019 [details] Full stack traces
That would indicate a problem in search module. But I'm not sure it's really in infinite loop. Are you searching a lot of files? Moving to search to evaluate the stacks...
This bug should not happen again (at least with such stacktraces). All the critical parts of stacktraces were initiated by cleaning search results of the previous search. The cleaning tasks (ResultModel.close()) was implemented in such a way that it removed result nodes one-by-one (ResultModel$FoundNode.removeFromSearch()) which caused repetitive sorting of the remaining nodes. This has changed since the time bug #41789 ("Clearing of previous ResultModel is performed in AWT thread") was fixed and the reason of blocking the search task no longer exists. I am marking this bug as FIXED. If you encounter the same or similar symptomps in NetBeans 4.0, feel free to reopen the bug.