Repository navigation
Resource Leaks in processing/app/Util.java #1432
Description
Debugging:
Hello, I was looking around the codebase for the sake of getting familiar with, where i noticed a couple problematic resource usage implementations that do not guarantee closure with either finally or encompassing with try ().
In multiple instances, if n exception occurs (disk full, corrupt ZIP, network timeout, etc.) file handles remain open. I believe on Windows this prevents subsequent deletion and on any OS it can exhaust the system’s file‑descriptor limit after repeated use.
Examples:
static public void unzip(File zipFile, File dest) throws IOException {
FileInputStream fis = new FileInputStream(zipFile);
CheckedInputStream checksum = new CheckedInputStream(fis, new Adler32());
ZipInputStream zis = new ZipInputStream(new BufferedInputStream(checksum));
ZipEntry entry;
while ((entry = zis.getNextEntry()) != null) {
final String name = entry.getName();
if (!name.startsWith(("__MACOSX"))) {
File currentFile = new File(dest, name);
if (entry.isDirectory()) {
currentFile.mkdirs();
} else {
File parentDir = currentFile.getParentFile();
// Sometimes the directory entries aren't already created
if (!parentDir.exists()) {
parentDir.mkdirs();
}
currentFile.createNewFile();
unzipEntry(zis, currentFile);
}
}
}
}ZipInputStream, CheckedInputStream, and FileInputStream are never closed. i think this may also contribute to update issues if there are any, as any crash may lock the temporary zip file, preventing its deletion.
A simple solution would be:
public static void unzip(File zipFile, File dest) throws IOException {
try (ZipInputStream zis = new ZipInputStream( new BufferedInputStream( new CheckedInputStream( new FileInputStream(zipFile), new Adler32())))) {
ZipEntry entry;
while ((entry = zis.getNextEntry()) != null) {
//rest of code
}
}
}this way all three underlying streams are closed automatically, even on exception.
This pattern repeats itself in other methods in the same file, some of which are: loadBytesRaw(File), saveFile(String, File) , copyFile(File, File).
Willing to work on this?
If i may, i'd be more than happy to be assigned to this issue as my first contribution to this codebase!
Activity
SalmaneKhalili commentedon Feb 15, 2026
If this sort of proposals are not welcomed, please let me know so that i can go ahead and close it. @SableRaf
SableRaf commentedon Feb 15, 2026
Hi @SalmaneKhalili, thanks for the issue and for your interest in contributing. We really appreciate bug reports like this, even if it can take us a bit of time to get to them. Thanks for your patience.
I’m forwarding this to the Processing project lead @catilac so it can be reviewed properly.
You can also join the Processing Discord if you’d like to chat with other contributors and maintainers:
https://discord.processing.org
catilac commentedon Feb 15, 2026
Amazing, @SalmaneKhalili thank you. Please write a failing test, and show it passing with your implementation
SalmaneKhalili commentedon Feb 15, 2026
Hello @catilac , thanks for giving me a chance. the is test added, I made sure to provide comments explaining what the program flow is.
result pre-solution:
after:
SalmaneKhalili commentedon Feb 17, 2026
Ill go ahead and mark this as closed since the PR has been merged, @SableRaf @catilac @tychedelia , Thanks for being welcoming. Ill be looking for other things to work on in the codebase! let me know if there is anything you want me to take a look at in particular. you can find in me in the discord under the tag @royistic.