diff options
| author | Yann Collet <cyan@fb.com> | 2018-05-06 01:24:11 (GMT) |
|---|---|---|
| committer | Yann Collet <cyan@fb.com> | 2018-05-06 01:24:11 (GMT) |
| commit | af127334670a5e7b710bbd6adb71aa7c3ef0cd72 (patch) | |
| tree | bab2c44f789bcd9b92a80802ca4de791e60b6e17 /lib/lz4frame.c | |
| parent | d358e33faa87e0293f27f272a8579de73f4ba938 (diff) | |
| download | lz4-af127334670a5e7b710bbd6adb71aa7c3ef0cd72.zip lz4-af127334670a5e7b710bbd6adb71aa7c3ef0cd72.tar.gz lz4-af127334670a5e7b710bbd6adb71aa7c3ef0cd72.tar.bz2 | |
fixed frametest error
The error can be reproduced using following command :
./frametest -v -i100000000 -s1659 -t31096808
It's actually a bug in the stream LZ4 API,
when starting a new stream
and providing a first chunk to complete with size < MINMATCH.
In which case, the chunk becomes a dictionary.
No hash was generated and stored,
but the chunk is accessible as default position 0 points to dictStart,
and position 0 is still within MAX_DISTANCE.
Then, next attempt to read 32-bits from position 0 fails.
The issue would have been mitigated by starting from index 64 KB,
effectively eliminating position 0 as too far away.
The proper fix is to eliminate such "dictionary" as too small.
Which is what this patch does.
Diffstat (limited to 'lib/lz4frame.c')
| -rw-r--r-- | lib/lz4frame.c | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/lib/lz4frame.c b/lib/lz4frame.c index aa7889b..4e40816 100644 --- a/lib/lz4frame.c +++ b/lib/lz4frame.c @@ -808,6 +808,7 @@ size_t LZ4F_compressUpdate(LZ4F_cctx* cctxPtr, LZ4F_lastBlockStatus lastBlockCompressed = notDone; compressFunc_t const compress = LZ4F_selectCompression(cctxPtr->prefs.frameInfo.blockMode, cctxPtr->prefs.compressionLevel); + DEBUGLOG(4, "LZ4F_compressUpdate (srcSize=%zu)", srcSize); if (cctxPtr->cStage != 1) return err0r(LZ4F_ERROR_GENERIC); if (dstCapacity < LZ4F_compressBound_internal(srcSize, &(cctxPtr->prefs), cctxPtr->tmpInSize)) |