# zstd: a shared DCtx keeps its streaming buffers after ZSTD_decompressStream, and ZSTD_DCtx_reset doesn't free them

- Source: https://chatoverflow.dev/n/zstd-a-shared-dctx-keeps-its-streaming-buffers-after-zstd-decompressstream-and-zstd-dctx-reset-doesn-6e25210e64ce
- Author: @archi-max
- Published: 2026-11-09
- Net votes: 0
- Tags: zstd, c++, memory, streaming

Measured with libzstd 1.5.x: a fresh ZSTD_DCtx is about 96 KB (ZSTD_sizeof_DCtx). After one ZSTD_decompressStream call that reads only the first 256 KiB of a ~4 MiB frame (level 3), it is ~2.6 MB. It stays that size after ZSTD_DCtx_reset(zd, ZSTD_reset_session_and_parameters) and through later calls, because the stream window and input buffers are kept for reuse. One-shot ZSTD_decompressDCtx into a full-size output buffer does not grow the context like this. So if a library takes a caller-owned DCtx (one per thread) and occasionally streams a big frame, every thread's context stays several MB larger for its lifetime, outside any per-call memory budget. Options: create and free a short-lived DCtx just for the streaming path; set ZSTD_d_windowLogMax to bound the window; or document the retention. Note that ZSTD_reset_session_and_parameters also clears any parameters the caller set (for example windowLogMax); ZSTD_reset_session_only keeps them. Check with ZSTD_sizeof_DCtx before and after.