Repository navigation
Test failure: GC/API/GC/Collect/Collect.dll #131721
Description
Failed in: runtime-coreclr jitstress2-jitstressregs 20260802.1
Failed tests:
coreclr windows x86 Checked jitstress2_jitstressregs1 @ Windows.10.Amd64.Open
- GC/API/GC/Collect/Collect.dll
Error message:
Assert.Equal() Failure: Values differ
Expected: 100
Actual: 1
Stack trace:
at Xunit.Assert.Equal[T](T expected, T actual, IEqualityComparer`1 comparer) in /_/src/arcade/src/Microsoft.DotNet.XUnitAssert/src/EqualityAsserts.cs:line 102
at Program.<<Main>$>g__TestExecutor14|0_15(StreamWriter tempLogSw, StreamWriter statsCsvSw, <>c__DisplayClass0_0&)
Metadata
Metadata
Assignees
Type
Projects
- Status
Activity
dotnet-policy-service commentedon Aug 3, 2026
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.
JulieLeeMSFT commentedon Aug 3, 2026
@AndyAyersMS, please check if this is a JIT issue.
AndyAyersMS commentedon Aug 3, 2026
Not a codegen issue; most likely a consequence of #126108 -- this test used to run in an isolated process.
@jkoritzinsky FYI
dotnet-policy-service commentedon Aug 4, 2026
Tagging subscribers to this area: @anicka-net, @dotnet/gc
See info in area-owners.md if you want to be subscribed.
kkokosa commentedon Aug 7, 2026
@jkoritzinsky - PR #126108 removed process isolation from
Collect,Collect0, andCollect1, putting them in the shared GC runner. In the failing ordering,GCHandle/AddrOfPinnedObjectruns immediately beforeCollect. It creates a pinnedGCHandle, never frees it, and performs a full collection. Consequently,Collecttests start with a live pinned object and generation boundaries shaped by earlier collections rather than a fresh heap. On x86 segment GC, pinned-plug demotion can leave the tested survivor in gen0, making the observed0 -> 0result valid even though the test assumes promotion. More generally,GC.Collectdoes not guarantee survivor promotion, so all three tests’ exact-generation assertions are sensitive to prior process-wide GC state.I restored isolation for those three tests here: https://github.com/kkokosa/runtime/tree/fix-131721-gc-collect-isolation, WDYT?
jkoritzinsky commentedon Aug 9, 2026
@kkokosa that resolution sounds great. If that fixes the issues, I'm happy with it.
You may also need to mark the tests as
JitOptimizationSensitive(as this should fix #131893 too).I'll add you as assignee for both issues for easy tracking.
VincentBu commentedon Aug 10, 2026
Failed in: runtime-coreclr jitstress-isas-x86 20260808.1
Failed tests:
Error message:
Stack trace:
kkokosa commentedon Aug 10, 2026
@jkoritzinsky I reproduced all three
Collect*failures locally in the shared x86 Checked runner by accumulating leaked pinned handles; freeing the handles or excludingAddrOfPinnedObjectproduced zero failures in 10,000 iterations. The failures also occur under FullOpt, soJitOptimizationSensitivedoes not seem warranted. This explains both #131893 and the above Linux x64 failure as the same shared-state problem rather than architecture- or JIT-mode-specific behavior. I've created #132076Restore isolation for GC Collect tests (dotnet#132076)