ant-notifications mailing list archives

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


Stephen Evanchik updated IVY-1305:

    Attachment: file_descriptor_leak.patch

> File descriptor leak in OSGI repo core while running buildobr Ant Task
> ----------------------------------------------------------------------
>                 Key: IVY-1305
>                 URL:
>             Project: Ivy
>          Issue Type: Bug
>          Components: Ant, Core
>    Affects Versions: trunk
>            Reporter: Stephen Evanchik
>         Attachments: file_descriptor_leak.patch
> 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

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


View raw message