[BUG] LZ4 Data Integritiy Lost with NVCOMP_TYPE_LONGLONG and NVCOMP_TYPE_ULONGLONG
NicolasDenoyelle opened this issue · 4 comments
Describe the bug
nvcomp lz4 manager fails to reconstruct valid data after a round-trip of compression, decompression when used with nvcomp types: NVCOMP_TYPE_LONGLONG
and NVCOMP_TYPE_ULONGLONG
Steps/Code to reproduce bug
Reproducer:
Compile with:
g++ -g -Wall -Wextra -Wall -std=c++17 -I/usr/local/cuda/include -I<path_to_nvcomp.h> nvcomp-lz4-reproducer.cpp -o reproducer -lcudart -lnvcomp && ./reproducer
Expected behavior
Expected behavior
The reproducer I attached compresses a buffer then decompresses the compressed buffer and check that the initial buffer and the final buffer are equal. The test fails the equality check.
The reproducer uses the high level API.
I checked that the manager inputs are within the ranges documented in lz4.h
The alignment constraint should be satisfied since the pointer is a value returned from cudaMalloc()
.
Environment details:
Bare-metal
Cuda Driver Version: 535.154.05
CUDA Version: 12.2
NVIDIA GeForce RTX 3050
nvcomp Version: 3.0.4 (no extensions)
Sorry. The LZ4 compressor only supports NVCOMP_TYPE_CHAR
, NVCOMP_TYPE_SHORT
, and NVCOMP_TYPE_INT
or the corresponding types with U
in them. It could be that the error isn't being reported/handled correctly, so I'll check that. Either way, it looks like the limitation isn't clearly documented, so I'll see if I can at least add a comment about it on nvcompBatchedLZ4Opts_t
in lz4.h
@ndickson-nvidia thanks for the quick reply.
I agree with your comment.
This issue has been labeled inactive-30d
due to no recent activity in the past 30 days. Please close this issue if no further response or action is needed. Otherwise, please respond with a comment indicating any updates or changes to the original issue and/or confirm this issue still needs to be addressed. This issue will be labeled inactive-90d
if there is no activity in the next 60 days.