commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COMPRESS-357) BZip2CompressorOutputStream can affect output stream incorrectly
Date Sat, 11 Jun 2016 16:20:21 GMT

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

Sebb commented on COMPRESS-357:
-------------------------------

Unfortunately AFAICT that still does not guarantee that all the variables will be safely published.

A variable is only safely published if the write happens-before the read.

One way to do this is where both the writer and reader synchronize on the *same* lock.

Another way I think is a shared volatile.
If thread A updates some fields and then writes the volatile, when thread B reads the same
volatile it will see any such updates.
But if thread A has since updated some fields, thread B could see either the original or a
later value.



> 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)

Mime
View raw message