[ 
https://issues.apache.org/jira/browse/COMPRESS-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15325974#comment-15325974
 ] 

Stefan Bodewig commented on COMPRESS-357:
-----------------------------------------

I'm not convinced we need to think about any publication other than the one of 
{{out}}.

This issue is about a thread calling {{finish}} and then the GC comes in and 
runs {{finalize}} which in turn runs {{finish}} again and the GC thread hasn't 
seen {{out}} having become {{null}}. There shouldn't be any concurrent reads to 
any other variables at all as the GC thread is the only one I want to care 
about - the rest is covered by declaring the whole class not thread safe.


> BZip2CompressorOutputStream can affect output stream incorrectly
> ----------------------------------------------------------------
>
>                 Key: COMPRESS-357
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-357
>             Project: Commons Compress
>          Issue Type: Bug
>          Components: Compressors
>    Affects Versions: 1.9, 1.11
>         Environment: multithreaded
>            Reporter: Richard Shapiro
>              Labels: easyfix
>             Fix For: 1.12
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> BZip2CompressorOutputStream has an unsynchronized finished() method, and an 
> unsynchronized finalize method. Finish checks to see if the output stream is 
> null, and if it is not it calls various methods, some of which write to the 
> output stream. 
> Now, consider something like this sequence.
> BZip2OutputStream s = ...
> ...
> s.close();
> s = null;
> After the s = null, the stream is garbage. At some point the garbage 
> collector call finalize(), which calls finish(). But, since the GC may be on 
> a different thread, there is no guarantee that the assignment this.out = null 
> in finish() has actually been made visible to the GC thread, which results in 
> bad data in the output stream.
> This is not a theoretical problem; In a part of a large project I'm working 
> on, this happens about 2% of the time. 
> The fixes are simple
> 1) synchronize finish() or
>   
> 2) don't call finish from finalize().
> A workaround is to derive a class and override the finalize() method. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to