Suppose this scenario, the calling sequences are Write, Flush, Write, Flush repeatedly, this is a very common scenario in web server.
When w.data is filled with data but doesn't reach the buffer size, calling Flush will send w.data[:w.idx] to channel and reset w.idx to zero. Here comes the problem because w.data[:w.idx] is a shadow copy of slice, that means a new call of Write and compression gorouting writes and reads the same underlaying byte array with an overlap index.
In v4 branch, the lz library may cause data corrupt if you have set concurrency > 1. The race problem happens at
https://github.com/pierrec/lz4/blob/v4/writer.go#L100 https://github.com/pierrec/lz4/blob/v4/writer.go#L159
Suppose this scenario, the calling sequences are
Write,Flush,Write,Flushrepeatedly, this is a very common scenario in web server. Whenw.datais filled with data but doesn't reach the buffer size, callingFlushwill sendw.data[:w.idx]to channel and resetw.idxto zero. Here comes the problem becausew.data[:w.idx]is a shadow copy of slice, that means a new call ofWriteand compression gorouting writes and reads the same underlaying byte array with an overlap index.