Test merged baseservices/threading time out in gcstress

[jakobbotsch]

All recent gcstress runs have timeouts in the "threading" groups. For example:
https://dev.azure.com/dnceng-public/public/_build/results?buildId=217737&view=results

Likely these tests should be striped in the same manner as HardwareIntrinsics. cc @trylek

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

Issue Details

---

All recent gcstress runs have timeouts in the "threading" groups. For example:
https://dev.azure.com/dnceng-public/public/_build/results?buildId=217737&view=results

Likely these tests should be striped in the same manner as HardwareIntrinsics. cc @trylek

Author:	jakobbotsch
Assignees:	-
Labels:	area-Infrastructure-coreclr
Milestone:	-

[JulieLeeMSFT]

Assigned to @markples.

[JulieLeeMSFT]

Failing gcstress-extra pipeline as well: https://dev.azure.com/dnceng-public/public/_build?definitionId=113

[markples]

This does not appear to be a need for test striping, though it might get there when all tests are running.

baseservices\threading\regressions\30032\30032.cs behaves differently under merged groups, and I'm not sure why - even when it is the first test in the list. Every time I've managed to break in with a debugger, it's sitting in WaitForPendingFinalizers (which the test calls), but the debugger is also having a lot of trouble doing anything when this test is running so I don't have a lot of information yet.

I will check if RequiresProcessIsolation in a merged group is sufficient to at least unblock things.

[trylek]

I recall that last year in my work on test merging I was hitting GC stress issues in tests that were somehow explicitly tampering with finalization. The working theory at that time was that this is possibly a bug in the GC stress implementation itself in the sense that by injecting the various extra GC calls into execution we can end up with a form of starvation where the finalization queue is getting filled in faster than it's pumped, causing exactly the type of hang you've described. IIRC the consensus at that time was to mark such tests as requiring out-of-proc execution because this behavior doesn't constitute an obvious product bug (in view of the fact that GC stress testing creates an artificial environment for the test) and is possibly hard to fix. I think this is one of the issue threads where we discussed this behavior:

#68529

[markples]

This may be more widespread. @BruceForstall proactively ran gcstress after JIT\Regression and more groups failed. Regression_1 and _2 both have some tests with WaitForPendingFinalizers in it, so I'm starting by marking them RequiresProcessIsolation. Regression_4 does not, but it did run for 2 hours (of the 4) before getting stuck on a test. The tests seem to slow down over time - I don't know if that's intrinsic to the tests or if GCStress degrades over time. I will try striping there.

[markples]

Fixed #84193