Nick Terrell
Nick Terrell
> but it may be able to emit compressed blocks with sequences encoded in RLE mode. > This however is a bit more difficult to assess (requires accessing the compressed...
What is that log representing? I don't see any RLE in it.
Just to confirm, you may choose either the BSD license, or the GPLv2 license.
> decompress/zstd_decompress_block.c: seq: litL=24, matchL=5, offset=239 This is super suspicious. Like Yann said, as long as a dictionary was used, this should be basically impossible for the compressor to generate....
If you think that the issue will eventually reproduce, you could add decompression verification directly after compression. Then when it fails, save both the original data, and the compressed data...
If trying out bitflips doesn't work, I highly suggest running a decompression directly after the compression. Then log the original blob if it fails. If you have that blob, and...
> static ZSTD_CCtx *comp_context = NULL; Are you using this code in a multi-threaded environment? `ZSTD_CCtx` are not thread-safe, and it looks like this would be using the same context...
Is the system your compressing on 32-bit or 64-bit?
What compression level are you using? From previous code snippets, it seems like level 1, but just want to verify. > We are still unable to find root cause of...
But, I don't think you should actually hit this case if you are using `v1.5.6`, because when we get close to needing to overflow correct, we opt to just reset...