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.
After doing multiple Find in Files with RegEx, NetBeans ran out of IO descriptors. Always used "Modify search" and then clicked on the class only in search results. NB showed a yellow search icon in the source in the line with the searched text (NB did show this icon for the first time - is this a new feature? It does not do this on other machines). Result: Could not compile anymore (StringIndexOutOfBoundsException: Bad file descriptor) and could not save anymore (IOException: Too many open files), although only one source was open in the editor. Attaching ide.log. Resolved by manually invoking GC from the Memory Toolbar. Using NB 3.5 RC2 with JDK 1.4.2 beta.
Created attachment 10401 [details] ide.log
I try it to reproduce on Linux RH and jdk1.4.1_02. This issue appeared only ontime. I'm using multiple search and regexpr. My steps are : 1) Open Find dialog 2) Type class* to reg. exp. textfield in Full text tab 3) Type a* to reg. exp. texfield in Object name tab 4) Click Start search 5) I double clicked on some objects 6) Click Modify search in Results window ans try change settings in find dialog (go to step 2) Changing priority to P3 because it is not 100% reproducible. When you use reg. expr., then IDE highlight full rows with yellow color. When you use search with substring then is highlited only found string. What is your reg. expresion ?
Thanks for the info. This is the RegEx: findNode\(".+/"\)
I found the way how to reproduce this bug. (Solaris 8 @ Sparc, JDK 1.4.1_01, NB 3.5 RC 2). 1) Start NetBeans. 2) Mount directory containing sources of module "openide". 3) Choose "Find..." from (a pop-up menu of the explorer node representing) the directory. 4) Enter "aha" into the Substring field and press OK. 5) Close the IDE. An exception claiming "too many open files" is written to ide.log and an error message reporting several exceptions having the same cause is displayed on the screen. You may need to repeat steps 3)-4) several times to reproduce the bug. On Solaris 8, it is enough to perform the steps just once since the limit for number of concurrently open files is low (1000 or less). On other platforms, the limit may be higher (several thousands) so it is necessary to perform the search several times to see syndroms of the bug.
The cause of this bug is that files being searched are not closed after search is finished on them so that every search increases number of currently open files. Because number of currently open files is limited in operating systems (OS), once the limit is reached, the OS does not allow to open any more files to the IDE. There are various symptoms of the bug. The Search function may not find all occurences of a string to be found. But even when the search results window is closed, the whole IDE is affected because no more files (e.g. configuration files) may be open, both for reading and writing. Exceptions from various parts of the IDE may be thrown at various times - it is common to these exceptions that they contain statement "too many open files".
Workaround: There is no good workaround for the bug. One may just defer the moment the limit is reached by searching rather smaller trees of files instead of searching large filesystems.
After reading your recent comments, I would say this bug qualifies as P1 for NB 3.5. It can cause very annoying and wrong behavior of NB.
Although the bug may cause strange behaviour of the under some circumstances, it does not seem to have strong impact on most users. This bug existed in the previous versions of the IDE (e.g. NB 3.4.1) and was not reported until last Friday. Since it is very close to release of NB 3.5, it is not desirable to make changes in NB 3.5 other than functionality blockers.
Another workaround: 1) Enable the Memory toolbar of the main IDE window. (Right-click on an empty toolbar area of the window and check the Memory toolbar.) 2) After each search, click on the icon of a waste bin on the Memory toolbar and wait for 5 seconds.
Created attachment 10456 [details] patch for NetBeans 3.5
The bug is fixed in the trunk. I won't mark it fixed until it is decided whether the fix goes to NB 3.5 or not.
Too late for 3.5. Please mark as RESOLVED with TM=4.0
Fixed in NB 4.0, won't be fixed in NB 3.5.
Verified in dev 200306110100.
*** Issue 35141 has been marked as a duplicate of this issue. ***
Since there's a patch why don't you release it using the Update Center? I think that's what the Update Center is for. I'm still suffering from this bug using the current 3.5.1 release.
Fixed also in Nevada Patch 1 and in Arrow.
If anyone wants to post the patch to the hotfix update center, please do so. The instructions are at http://www.netbeans.org/community/planning/35/release-fixes.html. Source diff of the patch is available in attachment "bug33856.diff" of this bug report. I will try to do it in a week but I would appreciate anybody's help.
*** Issue 37156 has been marked as a duplicate of this issue. ***