Skip to content

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

Open

Description

@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.

Activity

  1. dotnet-policy-service commented on Aug 3, 2026

    @dotnet-policy-service
    Contributor

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

  2. dotnet-policy-service commented on Aug 3, 2026

    @dotnet-policy-service
    Contributor

    Tagging subscribers to this area: @anicka-net, @dotnet/gc
    See info in area-owners.md if you want to be subscribed.

  3. self-assigned this
    on Aug 6, 2026
  4. added this to the Future milestone on Aug 6, 2026
  5. modified the milestones: Future, 12.0.0 on Aug 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

  • Status
    No status

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions