CLR_GCHEAPCOLLECT_KEYWORD triggers a GC twice

[kevingosse]

Description

I've looked into how to trigger a GC remotely using dotnet-trace (by enabling keyword 0x800000) and noticed that it actually triggered two GCs: one when the keyword is enabled, and one when it's disabled.

It looks like an bug in the code.

If I look at the corresponding code in the early days of coreclr, I can see that the call is wrapped in a if(bEnabled) condition, itself set as ((ControlCode == EVENT_CONTROL_CODE_ENABLE_PROVIDER) || (ControlCode == EVENT_CONTROL_CODE_CAPTURE_STATE)): https://github.com/dotnet/coreclr/blob/ef1e2ab328087c61a6878c1e84f4fc5d710aebce/src/vm/eventtrace.cpp#L4400

Now in the current version of the code, ControlCode is not checked anymore and so ForceGC is call even when disabling the keyword: https://github.com/dotnet/runtime/blob/main/src/coreclr/vm/eventtrace.cpp#L2425

Reproduction Steps

Run dotnet-trace collect -p <pid> --providers Microsoft-Windows-DotNETRuntime:800000.

Expected behavior

One GC is triggered when opening the session.

Actual behavior

One GC is triggered when opening the session, but then another one is triggered when closing the session.

Regression?

The problem was not there in .NET Framework, I believe it was introduced with eventpipes.

Known Workarounds

No response

Configuration

No response

Other information

No response