Not seeing this reported yet, so filing it.
While checking export code, spotted a few stream/zip handling bugs in java/src/processing/mode/java/JavaBuild.java:
-
new FileInputStream(...) is passed into saveStream() in multiple places, but that source stream is never closed.
-
ZipFile.getInputStream(entry) is also left open.
-
ZipFile itself is only closed on the happy path.
-
In the jar-entry read loop, if read() returns -1, remaining goes the wrong way and the loop can run forever.
This is in the Export Application path, so it’s not edge-only. Repeated exports can leak FDs/handles (worse on Windows due to file locks), and a bad/truncated jar can stall export.
Not seeing this reported yet, so filing it.
While checking export code, spotted a few stream/zip handling bugs in java/src/processing/mode/java/JavaBuild.java:
new FileInputStream(...) is passed into saveStream() in multiple places, but that source stream is never closed.
ZipFile.getInputStream(entry) is also left open.
ZipFile itself is only closed on the happy path.
In the jar-entry read loop, if read() returns -1, remaining goes the wrong way and the loop can run forever.
This is in the Export Application path, so it’s not edge-only. Repeated exports can leak FDs/handles (worse on Windows due to file locks), and a bad/truncated jar can stall export.