[
https://issues.apache.org/jira/browse/COMPRESS-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18134218#comment-18134218
]
Gary D. Gregory commented on COMPRESS-729:
------------------------------------------
I edited the description to remove the color noise which made the text
invisible in dark mode.
> 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)
