Test failure: GC/Features/HeapExpansion/bestfit-finalize/bestfit-finalize.cmd #132107

Activity

1. VincentBu

   added

   blocking-outerloopBlocking the 'runtime-coreclr outerloop' and 'runtime-libraries-coreclr outerloop' runsBlocking the 'runtime-coreclr outerloop' and 'runtime-libraries-coreclr outerloop' runs

   on Aug 11, 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 Aug 11, 2026
3. github-actions

   added

   area-CodeGen-coreclrCLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMICLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI

   on Aug 11, 2026
4. dotnet-policy-service commented on Aug 11, 2026

   

   dotnet-policy-servicebot

   on Aug 11, 2026 – with Dotnet Policy Service

   Contributor

   More actions

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

   self-assigned this

   on Aug 11, 2026
6. AndyAyersMS

   removed

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

   on Aug 11, 2026
7. AndyAyersMS

   added this to the 12.0.0 milestone on Aug 11, 2026
8. jakobbotsch

   added

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

   on Aug 24, 2026
9. JulieLeeMSFT commented on Aug 27, 2026

   

   JulieLeeMSFT

   on Aug 27, 2026

   Member

   More actions

   @AndyAyersMS, this failure is affecting many pipelines. PTAL.
10. JulieLeeMSFT

    added

    blocking-clean-ci-optionalBlocking optional rolling runsBlocking optional rolling runs

    on Aug 27, 2026
11. tannergooding commented on Sep 12, 2026

    

    tannergooding

    on Sep 12, 2026

    Member

    More actions

    The browser CoreCLR OOM is reproducible and appears to be finalizer starvation, rather than excessive live-request memory or a timeout.

    I replayed the normal/non-R2R failure from build 1593908 on #133774 using the original test DLL and browser Wasm Checked runtime from its GC-features Helix payload. The local host was Windows with Node 23.11.1 and tiering disabled, matching the CI Node version and scenario, but not its Linux container.

    With unchanged arguments 1 1200 100000 1094640032, the original binary reaches steady state after 15,970 requests, then throws OOM with GC.GetTotalMemory(false) reporting 3,841,467,072 bytes. The CI log reports 3,841,067,724 bytes.

    The relevant scheduling behavior is:

    • Each Request retains its survivor arrays and a pinned GCHandle; its finalizer releases the handle.
    • Go() synchronously constructs requests until five times the steady-state count: 79,850 for this seed.
    • Browser FinalizerThread::EnableFinalization defers execution to the host. SystemJS_ScheduleFinalization uses safeSetTimeout(..., 0).
    • This synchronous loop never returns control to the JS event loop. Collections continue, but the scheduled finalizers do not run, leaving dead requests' object graphs and pinned handles retained.

    An instrumented copy counted completed constructors and finalizers (the latter after pin.Free()), sampling memory once per 1,200 requests:

    Run	Constructed requests	Finalizers observed	Managed heap	Result
    No scheduling change	59,739	0	3,841,635,812 bytes at OOM	Exit 1
    Drain pending finalizers every 1,200 requests	79,850	76,547	376,938,324 bytes at the last observation; maximum sampled value 405,719,424 bytes	Exit 100

    The control performed 291 full collections without executing a single Request finalizer. The drain run still used natural collections; no GC.Collect() was added. The sampled maximum is not a continuous peak measurement, and the finalizer counts were observed before post-loop cleanup.

    An applicable test workaround is to add this immediately after requests[i] = new Request():

    if (OperatingSystem.IsBrowser() && (totalReqs % NumRequests == 0))
    {
        // Browser finalizers cannot run while this synchronous loop holds the JS thread.
        // Drain once per live-set-sized batch so dead requests can release their pins
        // and survivor arrays, without forcing collections.
        GC.WaitForPendingFinalizers();
    }

    On this runtime, WaitForPendingFinalizers drains synchronously outside the collection; it does not require returning to JavaScript. This preserves the random sequence, request count, allocation volume, survivor selection, pinning, and existing success/failure conditions.

    The uninstrumented workaround passed the failing seed, seed 0, and a two-outer-iteration run with the original 1200 100000 workload. Original and patched versions also passed on desktop. These were direct test-source compilations against the downloaded CI runtime, not a fresh runtime build or a rerun of the full Helix harness.

    This is a workaround for the test, not a general runtime fix: ordinary synchronous user allocation loops can encounter the same lack of finalizer progress. The reproduced failure is on CoreCLR Wasm; these experiments do not establish Mono Wasm behavior or a RyuJIT codegen defect.

    Note

    This analysis and workaround were drafted by GitHub Copilot from source inspection and local reproduction results.
12. lewing

    added a commit that references this issue on Oct 1, 2026

    Drain finalizers periodically in bestfit-finalize when multithreading…

    ...

    This issue will close once commit 9e2b506 is merged into the 'main' branch.

    9e2b506
13. lewing

    closed this as completedin #134996on Oct 1, 2026
14. lewing

    reopened this on Oct 1, 2026
15. lewing commented on Oct 1, 2026

    

    lewing

    on Oct 1, 2026

    Member

    More actions

    reopening temporarily to let ci clear