[wasm][R2R] Objects outlive the expected GC under ReadyToRun, breaking finalization/resurrection tests (Samples/gc, arrres_il_r)

[lewing]

Description

Under browser-wasm CoreCLR ReadyToRun (test code compiled with crossgen2), two GC finalization tests fail. In both, an object that should be unreachable at a GC.Collect() survives it and is finalized only at a later collection.

GC/Scenarios/Samples/gc (GC-scenarios1, out of process). The Introduction demo's objects are not finalized by the GC.Collect() + WaitForPendingFinalizers() that follows them. They are finalized one collection later, inside the Resurrection demo. The resurrection object is likewise not finalized at its collection, so ResObjHolder is still null:

Demo start: Object Resurrection.
   Obj(Resurrection): BaseObj Constructor
   Obj(Resurrection): ResurrectObj Constructor
   Forcing a garbage collection
   Waiting for Finalizers to complete
      Obj(Introduction): DerivedObj Finalize
      Obj(Introduction): BaseObj Finalize
      ...
   Finalizers are complete
System.NullReferenceException: Object reference not set to an instance of an object.
   at Application.ResurrectionDemo()
   at Application.TestEntryPoint()

JIT/Methodical/Arrays/misc/arrres_il_r (Methodical_r1, out of process). The test throws when the finalizer has not run and resurrected the object after a collection:

Unhandled exception. System.Exception: Exception of type 'System.Exception' was thrown.
   at GCTest_arrres_il.Test.Main()
Aborted(native code called abort())

arrres_il_r already notes that it depends on fully optimized code reporting precise lifetimes (JitOptimizationSensitive). It also fails in crossgen composite lanes (#109311).

Both tests pass in the browser-wasm interpreter leg, so this is specific to test code compiled with ReadyToRun on wasm. A likely cause is that wasm R2R reports a stack slot as live for longer than the object's actual lifetime. Compare #134803, where wasm reports stack roots as pinned.

Configuration

• browser-wasm, CoreCLR, Checked, R2R_CG2, priority 1
• runtime-coreclr outerloop on [wasm][CoreCLR] Add browser_wasm R2R_CG2 leg to runtime-coreclr outerloop #134960: build 1618757, Helix job de142d1f-704d-4976-80ab-a718a4a6635c

Note

This issue was drafted with GitHub Copilot assistance.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

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

[lewing]

Closing as a duplicate of #134803; this is expected behavior.

Under the wasm ABI ("GC References at Call Sites" in docs/design/coreclr/botr/clr-abi.md), GC refs that are live across a call, and all untracked GC refs, are spilled to the linear stack and reported pinned. Untracked refs are "effectively always live" (gcencode.cpp, TARGET_WASM). The same reporting that breaks generation promotion in GetGeneration here keeps objects reachable past the GC.Collect() that Samples/gc and arrres_il_r expect to finalize them. Both pass when their code is interpreted.

In #134960 both tests are now permanently skipped for wasm ReadyToRun only, rather than quarantined against this issue: gc through a ConditionalFact, and arrres_il_r (hand-written IL entry point) through R2RIncompatible.

Note

This comment was drafted with GitHub Copilot assistance.