Martin Zingg created COMPRESS-729:
-------------------------------------
Summary: ZipArchiveOutputStream.close() does not end the Deflater
when finish() fails
Key: COMPRESS-729
URL: https://issues.apache.org/jira/browse/COMPRESS-729
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.28.0
Reporter: Martin Zingg
{color:#14181f}ZipArchiveOutputStream.finish() ends the Deflater via
streamCompressor.close() only as its last{color}
{color:#14181f}step. If finish() throws (e.g. the target stream was closed by a
client abort), close() runs{color}
{color:#14181f}destroy() in its finally block, but destroy() only closes `out`;
the StreamCompressor and its{color}
{color:#14181f}Deflater are never ended. The native zlib memory (~256 KB per
stream) is then only freed when the{color}
{color:#14181f}stream is garbage collected, which on servers with large heaps
can take hours.{color}
{color:#14181f}{*}Steps{*}: write an entry to a ZipArchiveOutputStream whose
target throws IOException on write,{color}
{color:#14181f}then call close(); the Deflater is not ended.{color}
{color:#14181f}{*}Proposed fix{*}: in destroy() (or close()'s finally), also
call streamCompressor.close(), which{color}
{color:#14181f}ends the Deflater; Deflater.end() is idempotent, so the success
path is unaffected.{color}
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
