[browser][CoreCLR] GC.GetGCMemoryInfo(GCKind.Background) asserts when background GC is unavailable

[radekdoulik]

Description

CoreCLR browser WebAssembly is built without BACKGROUND_GC, but GC.GetGCMemoryInfo(GCKind.Background) remains a valid managed API call.

In Checked builds, preprocessing removes the branch handling gc_kind_background, so the call falls through to the gc_kind_any path and asserts. In Release builds, the same path can incorrectly return information for the most recent foreground collection.

Reproduction Steps

Build a Checked CoreCLR browser-WASM runtime and run the existing test:

src/tests/GC/API/GC/GetGCMemoryInfo.csproj

The minimal managed operation that triggers the failure is:

GCMemoryInfo info = GC.GetGCMemoryInfo(GCKind.Background);
Console.WriteLine(info.Index);

This was reproduced on current main at 3241014d5a2d09d044d112af0b5bed2d2ad94e96.

Expected behavior

When background GC is unavailable and no background collection can have occurred, the API should return an empty collection-specific record, including Index == 0.

Actual behavior

Checked builds fail with:

ASSERT FAILED
Expression: (gc_kind)kind == gc_kind_any
Location: src/coreclr/gc/interface.cpp
Function: GetMemoryInfo

Release builds can return information for a foreground collection instead of an empty background-GC record.

Regression?

No known regression. This appears to be a latent issue exposed by running the existing process-isolated test on CoreCLR browser-WASM.

Known Workarounds

Avoid requesting GCKind.Background on runtimes without background GC. The affected browser-WASM test can be marked with an ActiveIssue until the runtime behavior is corrected.

Configuration

• CoreCLR browser-WASM
• Checked and Release configurations
• BACKGROUND_GC not defined
• Reproduced with the Node-hosted runtime test infrastructure

Other information

The implementation should preserve the documented behavior for a requested GC kind that has never occurred: return an empty record rather than information for a different collection kind.

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: @anicka-net, @dotnet/gc
See info in area-owners.md if you want to be subscribed.