[ci-scan] Test failure: System.Net.Http.Functional.Tests.CompressedContentTest.BrotliZstd_SerializeToStream_WithCompressionLevel_RoundTrips (zstd OOM on x86) #130948

Activity

1. lewing

   added

   blocking-clean-ciBlocking PR or rolling runs of 'runtime' or 'runtime-extra-platforms'Blocking PR or rolling runs of 'runtime' or 'runtime-extra-platforms'

   Known Build ErrorUse this to report build issues in the .NET Helix tabUse this to report build issues in the .NET Helix tab

   on Jul 17, 2026
2. dotnet-policy-service

   added

   untriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner

   on Jul 17, 2026
3. github-actions

   added

   area-System.IO.Compression

   on Jul 17, 2026
4. dotnet-policy-service commented on Jul 17, 2026

   

   dotnet-policy-servicebot

   on Jul 17, 2026 – with Dotnet Policy Service

   Contributor

   More actions

   Tagging subscribers to this area: @karelz, @dotnet/area-system-io-compression
   See info in area-owners.md if you want to be subscribed.
5. rzikm

   added this to the 11.0.0 milestone on Jul 17, 2026
6. rzikm

   removed

   untriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner

   on Jul 17, 2026
7. github-actions commented on Jul 17, 2026

   

   github-actionsbot

   on Jul 17, 2026 – with GitHub Actions

   Contributor

   More actions

   Caution

   agentic threat detected
   Threat detection flagged this output in warn mode. Manual review is REQUIRED before any follow-up automation.

   Details

   The threat detection results could not be parsed.

   Review the workflow run logs for details.

   Workflow artifact: ci-fix
   Artifact kind: handoff
   Linked KBE: #130948

   Note

   AI/Copilot-generated root-cause hand-off (ci-failure-fix). No automated code change was produced: removing this failure would require either a public-API/behavioral decision about how CompressionLevel.SmallestSize maps to zstd on 32-bit, or muting the test on x86 (not allowed here). Looping in owners to fix forward.

   Root cause (read-only analysis)

   On the 32-bit (windows x86) leg, CompressedContentTest.BrotliZstd_SerializeToStream_WithCompressionLevel_RoundTrips(encoding: "zstd") throws OutOfMemoryException from the native Zstandard encoder:

   System.OutOfMemoryException : Insufficient memory to continue the execution of the program.
      at System.IO.Compression.ZstandardUtils.Throw(ZSTD_error error)
      at System.IO.Compression.ZstandardEncoder.CompressCore(...)
   

   The test compresses with CompressionLevel.SmallestSize. In ZstandardUtils.GetQualityFromCompressionLevel (src/libraries/System.IO.Compression/src/System/IO/Compression/Zstandard/ZstandardUtils.cs), CompressionLevel.SmallestSize maps to Quality_Max — zstd compression level 22. The public docs on ZstandardCompressionOptions.Quality already warn that "Values 20-22 require more memory and should be used with caution." At level 22 the encoder allocates a very large window plus working buffers (well beyond the input size), which exceeds the ~2 GB user address space available to a 32-bit process, so ZSTD_compressStream2 returns a memory-allocation error that surfaces as OutOfMemoryException.

   Because the memory demand is driven by the compression level (window log), not the 4 KB payload, shrinking the test input would not help. This is a streaming (ZstandardStream) path with no pledged source size, so the window cannot be auto-bounded to the input length the way a one-shot compress could.

   Why no in-bounds automated fix:

   • Capping/clamping the SmallestSize -> level-22 mapping (e.g. bounding windowLog on 32-bit, or mapping SmallestSize to a less memory-hungry level) is a public-behavior/design decision for the compression owners, outside small-fix bounds.
   • Skipping the test on x86 would mute coverage, which this workflow must not do.

   Evidence

   • Failing leg: Libraries Test Run release coreclr windows x86 Release — System.Net.Http.Functional.Tests.CompressedContentTest.BrotliZstd_SerializeToStream_WithCompressionLevel_RoundTrips (per the KBE Build error leg or test failing: line). Reproduced across all three Helix retries.
   • Failing build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1513558 (verified: completed/failed).
   • Mapping site: ZstandardUtils.GetQualityFromCompressionLevel (CompressionLevel.SmallestSize => Quality_Max).
   • No high-confidence regressing commit identified; this is a latent 32-bit memory limit for level-22 zstd rather than a recent regression.

   Suggested reviewers / area contacts

   • Area owners (area-System.IO.Compression): @karelz, @dotnet/area-system-io-compression

   A fix would likely bound the zstd window log (or the effective level) for the SmallestSize mapping on 32-bit processes, or otherwise make level 20-22 degrade gracefully under a constrained address space.

   Generated by CI Outer-Loop Failure Fixer · 340.6 AIC · ⊞ 18.2K · ◷
8. rzikm

   self-assigned this

   on Jul 20, 2026
9. rzikm

   closed this as completedin #130802on Jul 20, 2026
10. github-actions

    locked and limited conversation to collaborators on Aug 20, 2026