[ci-scan] Test failure: ZstandardStreamUnitTests OutOfMemoryException on tvOS CoreCLR #132459

Build Information

Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1555007

Build error leg or test failing: tvos-arm64 Release AllSubsets_CoreCLR - System.IO.Compression.Tests

Error Details

[FAIL] System.IO.Compression.ZstandardStreamUnitTests.CompressionLevel_SizeInOrder(testFile: "UncompressedTestFiles/TestDocument.doc")
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(ReadOnlySpan`1 source, Span`1 destination, Int32& bytesConsumed, Int32& bytesWritten, ZstdEndDirective endDirective)
   at System.IO.Compression.ZstandardStream.WriteCoreAsync(ReadOnlyMemory`1 buffer, CancellationToken cancellationToken, Boolean isFinalBlock, Boolean flush, Boolean throwOnActiveRwOp)

[FAIL] System.IO.Compression.ZstandardStreamUnitTests.TestCompressCtor
Assert.All() Failure: 3 out of 13 items in the collection did not pass.
[10]: Error: Insufficient memory to continue the execution of the program.
[11]: Error: Insufficient memory to continue the execution of the program.
[12]: Error: Insufficient memory to continue the execution of the program.

Error Message

{
  "ErrorMessage": [
    "[FAIL] System.IO.Compression.ZstandardStreamUnitTests",
    "Insufficient memory to continue the execution of the program."
  ],
  "ErrorPattern": "",
  "BuildRetry": true,
  "ExcludeConsoleLog": false
}

Failure details:

System.IO.Compression.Tests intermittently fails on physical tvOS CoreCLR when Zstandard tests use CompressionLevel.SmallestSize.

Four failures share the same native Zstd allocation failure:

• ZstandardStreamUnitTests.CompressionLevel_SizeInOrder("UncompressedTestFiles/TestDocument.doc")
• ZstandardStreamUnitTests.CompressionLevel_SizeInOrder("UncompressedTestFiles/TestDocument.pdf")
• ZstandardStreamUnitTests.CompressionLevel_SizeInOrder("UncompressedTestFiles/sum")
• ZstandardStreamUnitTests.TestCompressCtor

The first three fail on the SmallestSize operation. TestCompressCtor builds a zero-based factory list containing one CompressionMode.Compress factory followed by three factories for each compression level. The Zstandard overrides forward those factories to the concrete constructors. The failed items map to:

• [10]: new ZstandardStream(stream, CompressionLevel.SmallestSize)
• [11]: new ZstandardStream(stream, CompressionLevel.SmallestSize, leaveOpen: true)
• [12]: new ZstandardStream(stream, CompressionLevel.SmallestSize, leaveOpen: false)

Affected leg:

• tvos-arm64 Release AllSubsets_CoreCLR

Test results:

• CompressionLevel_SizeInOrder result
• TestCompressCtor result

Console log:

• https://helix.dot.net/api/2019-06-17/jobs/22bb8241-6a3c-4036-b844-f0859313552d/workitems/System.IO.Compression.Tests/console

Regression status:

Not established. The same tests passed in the two preceding daily builds on the same AppleTV5,3 device model:

• Build 1554672, passing work item
• Build 1554343, passing work item

The KBE signature was verified against the failing Helix console. Its allocation-error line is absent from both passing consoles.

Configuration:

• .NET: 11.0.0-preview.6.26359.118
• Repository commit: a36e3c1c9a993f0b4c6db87f033105f0bb364f3b
• Runtime: CoreCLR composite ReadyToRun
• Target: physical tvOS 26.2 (23K54), arm64
• Device: AppleTV5,3 / J42dAP
• Device memory: 1.97 GB
• Helix host: DNCENGMAC108, macOS 15.7

Analysis:

CompressionLevel.SmallestSize maps to Zstd's maximum quality:

The test already replaces SmallestSize with Optimal for 32-bit processes because maximum-quality Zstandard compression needs 800+ MB of working memory and can fail intermittently:

The evidence is consistent with an intermittent native allocation limit or memory-pressure condition on a constrained physical device. It does not yet prove a product correctness regression.

BuildRetry is set to true as a temporary mitigation. Build Analysis may retry the whole build once when this signature matches a first-attempt failure. The two preceding equivalent runs passed, so a retry has a reasonable chance of clearing transient device memory pressure while the test's memory assumption is investigated.

The cpu_resource report and mlaunch exit 137 are not the root failure:

• The resource report says Action taken: none.
• Both preceding passing work items also produced a cpu_resource report.
• Both preceding passing work items also logged Process mlaunch exited with 137 after XHarness detected the test-end marker.

Recommended action:

Determine whether maximum-quality compression is expected to succeed reliably within the supported tvOS device memory budget.

If the allocation failure is an expected platform constraint, extend the test's constrained-memory handling to physical tvOS or isolate the maximum-quality coverage so it does not fail unrelated compression coverage.

Known issue validation

Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=1555007
Error message validated: [[FAIL] System.IO.Compression.ZstandardStreamUnitTests Insufficient memory to continue the execution of the program.]
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 8/18/2026 11:52:22 AM UTC

Report

Summary