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.

Bug 53451 - "FileNotFoundException: .../work/xmlresults/suites/TEST-... (Too many open files)" from XMLReporter.recreateOutput
Summary: "FileNotFoundException: .../work/xmlresults/suites/TEST-... (Too many open fi...
Status: RESOLVED WORKSFORME
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 4.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: Jaroslav Tulach
URL:
Keywords: TEST
: 53714 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-01-14 21:38 UTC by Jesse Glick
Modified: 2008-12-22 19:05 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Sample output log (32.64 KB, text/plain)
2005-01-14 21:39 UTC, Jesse Glick
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2005-01-14 21:38:58 UTC
I have noticed that I get this exception printed
to console whenever I am running core/unit commit
tests. The tests seem to pass nonetheless, and I
can even get a complete summary for the whole
commit validation (though if I run just "ant -f
core/test/build.xml -Dxtest.attribs=commit", the
summary page is not complete). Note that
BundleKeysTest does not print an error.

I am running Fedora Core 3 (2.6.10 kernel), no
ulimit, plenty of memory etc. Reproducible on
various JDK versions.

Perhaps some code is not closing file output
streams when it should?
Comment 1 Jesse Glick 2005-01-14 21:39:18 UTC
Created attachment 19706 [details]
Sample output log
Comment 2 Jesse Glick 2005-01-14 21:41:46 UTC
None of the other logs (e.g. ide_qa-functional.log) show such a
problem. Perhaps it is ValidateLayerConsistencyTest which exhausts all
available file descriptors, since that is the first test to fail?
Comment 3 Jesse Glick 2005-01-14 22:00:01 UTC
It is a leak in
ValidateLayerConsistencyTest.testIfOneFileIsDefinedTwiceByDifferentModulesTheyNeedToHaveMutualDependency;
can prevent bug symptoms by replacing

  FileSystem fs = new XMLFileSystem(layerURL);

with

  FileSystem fs = new XMLFileSystem();

Bug in XMLFileSystem perhaps?
Comment 4 Jesse Glick 2005-01-14 22:23:31 UTC
Using some logging and strace, seems that it gets almost halfway
through the list of modules to check and then starts getting "Too many
open files" when opening module JARs (this is before it even tries to
print output). Note that I looked at a module JAR which it had loaded
*before* the first module JAR to fail when opened with EMFILE, and
found that its file descriptor was in fact not being closed. This
lends support to my suspicion that there is a file handle leak in
XMLFileSystem, though I cannot find it.

Calling URLConnection.setDefaultUseCaches(false) does not appear to help.
Comment 5 Jesse Glick 2005-01-14 22:27:35 UTC
Note that you could fix the test by getting rid of XMLFileSystem and
just directly parsing the layers - all you need to look for are
<folder> and <file> and the 'name' attribute. Would probably run
faster too.
Comment 6 Jan Pokorsky 2005-01-24 15:18:27 UTC
*** Issue 53714 has been marked as a duplicate of this issue. ***
Comment 7 Jan Pokorsky 2005-01-24 15:30:14 UTC
[ant 1.6.2, jdk 1.4.2_06-b03, WinXP sp1]
I can also reproduce this pretty often. Worse, it ends up with a swing
dialog that I have to close.

Test Bag: Before Commit Validation in IDE
# Some suites did not finish correctly:

    * org.netbeans.core.projects.ValidateLayerConsistencyTest
    * org.netbeans.core.ValidateLayerAutomountTest

Log file is attached to issue #53714
Comment 8 Jaroslav Tulach 2005-02-04 12:28:40 UTC
I know that when one do:

URL u = ..;
InputStream i1 = u.openStream();
InputStream i2 = u.openStream();

then it is true that i1 == i2. So I tried to use this in the test and
I hope it helps. Let me know if not.
Comment 9 Tomas Danek 2005-08-01 11:35:48 UTC
if no further comment provided, i'll close.