Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #349121 +++ From bug #300589, Stephan found the following: OK, since this bug is still relevant, I had a quick look at the source of org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.readIntoArray(BundleEntry) It looks like a very simply file handle leak here: the InputStream "is" might be allocated in be.getInputStream() but is never closed. Looks like a simple } finally { if (is != null) is.close(); } might solve the issue at this location (there might be more!!). I'm pretty confident that this helps because I previously had the same bug pattern in my code and the finally did fix one instance of "Too many open files" :) Then in a second comments he adds: More evidence: the error message in bug 349073 reads "Error reading signed content". That's logged from org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.verifyContent() When drilling into verifierFactory.getSignedContent(inputFile); we actually get to the same readIntoArray() method mentioned in my previous comment.
Patch from bug349192 will apply to 3.7.1.
Reducing severity. I do not consider this bug to be severe. It should only effect directory style bundles since the input streams from zip files will automatically get closed when the zip file is closed. Also this bug has been around since 3.4 at least.
(In reply to comment #2) > Reducing severity. I do not consider this bug to be severe. It should only > effect directory style bundles since the input streams from zip files will > automatically get closed when the zip file is closed. Also this bug has been > around since 3.4 at least. I won't argue with you about severity as triggering this bug seems to be rare indeed. Just wanted to mention that when I first saw indications of this bug the effect was that eclipse wiped itself off the disk - - not exactly nice :)
patch released to 3.7 maint branch.
