[
https://issues.apache.org/jira/browse/COMPRESS-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated COMPRESS-729:
-------------------------------------
Description:
ZipArchiveOutputStream.finish() ends the Deflater via streamCompressor.close()
only as its last
step. If finish() throws (e.g. the target stream was closed by a client abort),
close() runs
destroy() in its finally block, but destroy() only closes `out`; the
StreamCompressor and its
Deflater are never ended. The native zlib memory (~256 KB per stream) is then
only freed when the
stream is garbage collected, which on servers with large heaps can take hours.
Steps: write an entry to a ZipArchiveOutputStream whose target throws
IOException on write,
then call close(); the Deflater is not ended.
Proposed fix: in destroy() (or close()'s finally), also call
streamCompressor.close(), which
ends the Deflater; Deflater.end() is idempotent, so the success path is
unaffected.
was:
{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}
> 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
> Priority: Minor
>
> ZipArchiveOutputStream.finish() ends the Deflater via
> streamCompressor.close() only as its last
> step. If finish() throws (e.g. the target stream was closed by a client
> abort), close() runs
> destroy() in its finally block, but destroy() only closes `out`; the
> StreamCompressor and its
> Deflater are never ended. The native zlib memory (~256 KB per stream) is then
> only freed when the
> stream is garbage collected, which on servers with large heaps can take hours.
>
> Steps: write an entry to a ZipArchiveOutputStream whose target throws
> IOException on write,
> then call close(); the Deflater is not ended.
>
> Proposed fix: in destroy() (or close()'s finally), also call
> streamCompressor.close(), which
> ends the Deflater; Deflater.end() is idempotent, so the success path is
> unaffected.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
