A created ZipInputStream is never closed and this causes a resource leakage
See original GitHub issueWhen using org.zeroturnaround.zip.ZipUtil#iterate(java.io.InputStream, org.zeroturnaround.zip.ZipEntryCallback, java.nio.charset.Charset)
, a ZipInputStream
instance is created which is never closed. This causes a resource leakage or even a native memory leak.
Issue Analytics
- State:
- Created 6 years ago
- Comments:6 (3 by maintainers)
Top Results From Across the Web
Strange "Resource leak: stream is never closed" with try-with ...
This appears to be a known bug in Eclipse: [compiler][resource] Bad resource leak problem on return inside while loop (resource passed on in ......
Read more >358903 – Filter practically unimportant resource leak warnings
With this patch and with resource leak warning enabled I'm down to 4 warnings in JDT/Core: Resource leak: 'file' is never closed Util.java ......
Read more >ZipFile.close() does not close ZipFileInputStreams, contrary to ...
This leads to a native memory leak if the input streams are not closed explicitly, because the native buffer created for each ZipEntry...
Read more >Resource leak: 'input' is never closed VisualStudioCode(VSC ...
In this video I show that when we coding in java programming throw visual studio code editor, we see a common problem ,that's...
Read more >IDS04-J. Safely extract files from ZipInputStream - Confluence
A number of security concerns must be considered when extracting file entries from a ZIP file using java.util.zip.ZipInputStream . File names may contain...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Thanks for pointing this out. To keep the semantics I would wrap the passed-in InputStream into an uncloseable InputStream, pass this to the ZipInputStream and close it so that the original stream remains unclosed. We need to keep it open if it’s actually an entry of another ZipInputStream e.g.
@reinra Looks great. Thanks for the quick turnaround. 😃