[ci-scan] jit64/regress/vsw/373472/test_il OutOfMemoryException under GCStress=0xC JitStress=2 on windows-x86

[github-actions]

Reasoning

JIT/jit64/regress/vsw/373472/test_il/test_il.dll (StrideTest) fails with System.OutOfMemoryException under DOTNET_GCStress=0xC DOTNET_JitStress=2 on Windows x86. The test allocates strided memory patterns and exercises JIT64 regression scenarios; with GC stress enabled, the continuous GC pressure during StrideTest.Test1/2/3() exhausts the small 32-bit address space, causing OOM. The aggregate result is Assert.Equal() Failure: Expected 100, Actual 1 (3/3 sub-tests threw OOM → return code 1 instead of 100). Confirmed in two consecutive builds of pipeline 113 (gcstress-extra).

Impact on platforms

• windows-x86 · pipeline 113 (gcstress-extra) · build 1406727 · work item jit64_5.0.1 · Helix job 2e052d23 · queue Windows.10.Amd64.Open · exit code 1
• Confirmed recurring: same failure in work item jit64_5.0.1 in build 1406299 (2026-05-02, Helix job 3c4bb988)

Errors log

Running test: JIT/jit64/regress/vsw/373472/test_il/test_il.dll
test1 exception: System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
   at StrideTest.Test1()
Test1 failed
test2 exception: System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
   at StrideTest.Test2()
Test2 failed
test3 exception: System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
   at StrideTest.Test3()
Test3 failed
Xunit.Sdk.EqualException: Assert.Equal() Failure: Values differ
Expected: 100
Actual:   1
23:03:11.985 Failed test: JIT/jit64/regress/vsw/373472/test_il/test_il.dll
```

Stress mode env:
```
DOTNET_TieredCompilation=0
DOTNET_GCStress=0xC
DOTNET_JitStress=2

First build it occurred

First seen in this scan window: build 1406299, finished 2026-05-02T23:58:10Z. Confirmed in build 1406727, finished 2026-05-04T00:01:59Z. Scanned window only — true origin may be earlier. Occurrences in window: 2 builds.

Recommended action

1. Root cause: The 32-bit process address space on x86 is exhausted when GCStress=0xC triggers continuous full-heap compaction while StrideTest allocates large strided buffers. This is x86-specific (limited VA space) and stress-mode-specific.
2. Short-term: Skip or suppress test_il under GCStress on x86. The test file is under src/tests/JIT/jit64/regress/vsw/373472/test_il/. Add appropriate [GCStressPass] metadata or an xunit Skip attribute when DOTNET_GCStress is set.
3. Investigation: Check whether the OOM happens because the GC heap itself is fragmented under stress or because the test's own allocations exceed VA. Running with DOTNET_GCgen0size=1024 and DOTNET_GCStress=0x4 only (no compaction) may narrow this down.
4. Owner: @dotnet/area-infrastructure-coreclr-jit for JIT regression tests; @dotnet/area-gc for GC stress interactions on x86.
5. Files: src/tests/JIT/jit64/regress/vsw/373472/test_il/test_il.cs (or .il), src/tests/JIT/jit64/regress/vsw/373472/test_il/test_il.csproj.

Note

🔒 Integrity filter blocked 4 items

The following items were blocked because they don't meet the GitHub integrity level.

• #125371 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #125825 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #55803 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• #127128 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

Generated by CI Outer-Loop Failure Scanner · ● 19.3M · ◷

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[JulieLeeMSFT]

Duplicate: #127128
CC @kotlarmilos