[wasm][R2R] HeapExpansion bestfit tests trap after reaching steady state

[lewing]

Description

The three GC/Features/HeapExpansion/bestfit* tests trap in the browser-wasm CoreCLR ReadyToRun lane after reaching steady state.

Affected projects:

• bestfit
• bestfit_1
• bestfit-finalize

Reproduction Steps

Run the runtime-wasm-non-libtests pipeline with ReadyToRun tests enabled on dotnet/runtime commit ef1850bdc9e7d142888247d9bb5df3b74a7ae341 (Azure DevOps build 1588226). The failures are present in both published R2R test runs, including run 43835190.

Expected behavior

Each test completes its allocation workload and returns 100.

Actual behavior

Each test reaches steady state and then traps from its R2R entry point. For example:

Using random seed: -1993479968
Took 7176 iterations to reach steady state
RuntimeError: unreachable
    at bestfit_Fragment_Test__Main
    at WasmInterpreterToR2RThunk(iip)
    at WasmR2RToInterpreterThunk(iip)

The bestfit-finalize and bestfit_1 variants have the same signature with their respective Fragment.Test.Main entry points.

Regression?

Unknown. This was reproduced on current main during the #133305 census.

Known Workarounds

Mark only these three projects R2R-incompatible for browser CoreCLR. Their normal browser execution, WASI, non-browser, and other GC coverage remain enabled.

Configuration

• dotnet/runtime commit ef1850bdc9e7d142888247d9bb5df3b74a7ae341
• CoreCLR browser-wasm
• Checked runtime
• ReadyToRun / crossgen2
• Node.js 23.11.1

Other information

Tracking issue: #133305.

Note

This issue was authored with GitHub Copilot.

[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: @dotnet/crossgen-contrib
See info in area-owners.md if you want to be subscribed.

[AndyAyersMS]

This looks like it is the same problem as #133465, testing it with #133528 now.

[AndyAyersMS]

Yep same issue.