System.Diagnostics.Process.Tests hangs with parallel test collections on macOS #135294

Summary

System.Diagnostics.Process.Tests intermittently hangs when test classes run concurrently on macOS. This has occurred on both x64 Mono and arm64 Checked CoreCLR while validating #135160, which removes assembly-wide serialization after isolating ambient-state-changing tests with RemoteExecutor.

This issue tracks diagnosing the macOS stall and safely restoring class-level parallelism there. It is separate from #135001's Windows x86 execution-budget investigation; a shared cause has not been established.

Failing runs

Build 1623874, PR head 84d90da192a2394172e79aea4a174481ab675bea:

Both logs report ProcessWaitingTests.WaitAsyncChain failing with TaskCanceledException, followed by a fixture-disposal assertion failure at ProcessTestBase.Dispose: Kill() is followed by a bounded WaitForExit() that returns false.

Several other classes then remain active until executor termination. Common examples include:

• ProcessTests.Kill_EntireProcessTree_True_EntireTreeTerminated
• ProcessWaitingTests.CurrentProcess_WaitNeverCompletes (the test only requests a zero- or ten-millisecond wait)
• ProcessMultiplexingTests and ProcessStreamingTests cases
• WaitForExitStatusTests cases

Logs:

• x64 Mono
• arm64 Checked CoreCLR

The x64 Mono leg also timed out in build 1622931, with process-tree termination and a multiplexed-read test remaining active for many minutes.

Passing comparison and current mitigation

The earlier parallel run in build 1622776 passed on both platforms: the full Process work items completed in approximately 23 seconds on x64 Mono and 41 seconds on arm64 Checked CoreCLR. WaitAsyncChain and process-tree termination completed in roughly 1-2 seconds. These are different machines/revisions, not a controlled serial/parallel comparison; they establish that the failure is intermittent.

#135160 currently retains the original CollectionPerAssembly behavior for desktop macOS, while keeping class-level parallelism on other targets and retaining the RemoteExecutor isolation improvements. This is a compatibility safeguard, not a root-cause fix. Review request to track the fallback.

Investigation needed

The existing failing work items uploaded console/executor logs only: no process dump, thread stacks, or completed results XML. The broad loss of progress suggests a shared process-management or synchronization problem, but the exact blocked operation is unknown. Shared Unix process-start and SIGCHLD/child-reaping synchronization is a candidate, not an established cause.

Replay the same macOS payload with serial and class-parallel execution, capturing parent/child thread stacks and process state externally while it stalls. Use that evidence to determine the cause and remove the macOS serialization fallback without dropping coverage or increasing timeouts.