ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Evanchik (JIRA)" <>
Subject [jira] [Created] (IVY-1305) File descriptor leak in OSGI repo core while running buildobr Ant Task
Date Fri, 15 Jul 2011 01:20:01 GMT
File descriptor leak in OSGI repo core while running buildobr Ant Task

                 Key: IVY-1305
             Project: Ivy
          Issue Type: Bug
          Components: Ant, Core
    Affects Versions: trunk
            Reporter: Stephen Evanchik

I have Ivy declared as an extension to the Eclipse Ant infrastructure. This means that I can
execute Ant from inside Eclipse using the AntRunner class. When Ant is invoked it will share
the same JVM as the main Eclipse install. This makes the main Eclipse install susceptible
to problems in any Ant Task including memory and file descriptor leaks.

According to my superficial understanding of the OSGI repo code in Ivy it appears that there
is a FSIterable class which iterates over a filesystem looking for JARs/OSGi bundles. This
list is built so that it can be traversed via an Iterator: FSManifestIterator.

In that Iterator the Iterator.hasNext() method instantiates a JarInputStream but does not
close it. When JarInputStream is allocated via the FileInputStream a FileDescriptor is allocated.
FileDescriptors are often a limited resource on Linux systems. In my case Fedora 15 I am limited
to 1024 per-process. I could easily increase the limit but then users of my Eclipse plugin
would also have to do that which is not desirable.

Additionally, the lack of an call to JarInputStream.close() means the cleanup is left to the
finalizer which is not guaranteed to run in a predictable manner. Finally, there have been
several problems with InflaterInputStreams polluting the shared Inflater pool when relying
on finalizers cleaning up InputStreams (See here for an example:

Given all this I think it better to practively close the JarInputStream after it is not needed.

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message