Closed davies closed 8 years ago
Since the LZ4BlockOutputStream could make sure that the originalLen is always larger than compressedLen, this is not bug actual.
I'm continuing to investigate a stream corruption bug, so here are some notes based on me revisiting this PR (to hopefully save time for anyone else who comes across this):
The bug that @davies identified here looks like a duplicate of #70, where @mtopolnik described it as a performance issue (due to possible overallocation of more buffer space than is really needed).
The current code would be incorrect if the compressed data was longer than the original data, in which case we might write past the end of the buffer, but it turns out that LZ4BlockOutputStream has checks which switch from COMPRESSION_METHOD_LZ4
to COMPRESSION_METHOD_RAW
in case the LZ4-compressed data is longer than the original data (see discussion at https://github.com/apache/spark/pull/15632#discussion_r85047248)..
I agree with other commenters on the linked Spark PR who pointed out that the existing code is somewhat dodgy / hard-to-understand because it's implicitly relying on guarantees from a distant part of the code. If the current behavior is intended then there should at least be a comment explaining the invariants that make it safe. Given the potential perf. impact mentioned in #70, though, I'd rather see this fixed completely via a code change to use the safer comparison.
Yes, I agree. I'll fix the code.
Do you still see the corrupted stream error in Spark? I think the problem is specific to your copied version of lz4-java, which supports concatenated stream, because the original version does not call LZ4BlockInputStream.refill() from LZ4BlockInputStream.available(). It looks weird to me that available() calls refill(), because usually available() should not call a blocking method like refill().
Fixed by c8f4371931a356036a201f01475df99e4be7726c.
When LZ4 is used to compresss the shuffle files in Spark, we saw these failure:
LZ4BlockInputStream is a fork of LZ4BlockInputStream here, in order to support concated stream: https://github.com/davies/lz4-java/commit/cc1fa940ac57cc66a0b937300f805d37e2bf8411
They have the same bug
I think
compressedBuffer.length < originalLen
should becompressedBuffer.length < compressedLen