RTech: fixed streamed pak decoding progression bug

During beta tests on a Linux system, we encountered an issue where the I/O could be slower and thus result in not enough bytes being streamed by the time we invoke the decoder (lenStreamed == bufSizeNeeded at this point), after 16 calls with lenStreamed == bufSizeNeeded, the engine errors as ZSTD_NO_FORWARD_PROGRESS_MAX would be reached. Added value of 'ZSTD_nextSrcSizeToDecompress()' to 'PakDecoder_s::bufferSizeNeeded' to make sure we never call the decoder without any new streamed bytes. Also increased the value of ZSTD_NO_FORWARD_PROGRESS_MAX to 1024 since this fixed the issue without applying the aforementioned patch, this was increased as a hardening measure.
This commit is contained in:
Kawe Mazidjatari 2024-04-16 02:17:41 +02:00
parent 59d4affebe
commit 9de5f4988f
2 changed files with 5 additions and 3 deletions

View File

@ -620,7 +620,8 @@ bool Pak_ZStdStreamDecode(PakDecoder_s* const decoder, const PakRingBufferFrame_
inFrame.frameLen, NULL
};
const size_t ret = ZSTD_decompressStream(decoder->zstreamContext, &outBuffer, &inBuffer);
ZSTD_DStream* const dctx = decoder->zstreamContext;
const size_t ret = ZSTD_decompressStream(dctx, &outBuffer, &inBuffer);
if (ZSTD_isError(ret))
{
@ -646,14 +647,14 @@ bool Pak_ZStdStreamDecode(PakDecoder_s* const decoder, const PakRingBufferFrame_
//
// if the input stream has fully decoded, this should equal the size of the
// encoded pak file
decoder->bufferSizeNeeded = decoder->inBufBytePos;
decoder->bufferSizeNeeded = decoder->inBufBytePos + ZSTD_nextSrcSizeToDecompress(dctx);
const bool decoded = ret == NULL;
// zstd decoder no longer necessary at this point, deallocate
if (decoded)
{
ZSTD_freeDStream(decoder->zstreamContext);
ZSTD_freeDStream(dctx);
decoder->zstreamContext = nullptr;
}

View File

@ -94,5 +94,6 @@ thirdparty_suppress_warnings()
target_compile_definitions( ${PROJECT_NAME} PRIVATE
"ZSTD_MULTITHREAD"
"ZSTD_NO_FORWARD_PROGRESS_MAX=1024"
"DEBUGLEVEL=0"
)