run_tests(mode="PlayMode") hangs the Editor on Linux/Vulkan — no test starts, futex_do_wait

Summary

run_tests(mode="PlayMode") never starts any test and hangs the Unity Editor. EditMode runs are fine, and entering Play Mode manually is fine. Only the PlayMode test run is affected.

Environment

Symptom

run_tests(mode="PlayMode", test_names=[...], init_timeout=180000)
  -> status: running
  -> ... 180 s ...
  -> status: failed
     error: "Test job failed to initialize (tests did not start within timeout)"
     progress.completed: 0

Meanwhile the Editor:

• Editor.log stops growing — 0 bytes added across samples 5 s, 8 s and 10 s apart;
• ~140 % CPU, 173 threads;
• /proc/<pid>/wchan = futex_do_wait;
• stops answering the bridge: Unity session not ready ... (ping not answered);
• does not respond to SIGTERM — left for 5 minutes with no progress; SIGKILL required.

Last log lines before the freeze:

MCP-FOR-UNITY: [TestRunnerNoThrottle] Applied No Throttling for test run.
MCPForUnity.Editor.Services.TestJobManager:StartJob (UnityEditor.TestTools.TestRunner.Api.TestMode, ...)
MCP-FOR-UNITY: [TestJobManager] Job <id> failed to initialize within 180000ms, auto-failing

Often preceded by (Linux-specific):

(unityhub-unity-editor-2022.3.22f1:<pid>): GLib-GIO-CRITICAL **:
  g_dbus_proxy_call_sync_internal: assertion 'G_IS_DBUS_PROXY (proxy)' failed

Reproduction

Three out of three attempts, two of which rule out the usual explanations:

Case 3 rules out the scene; case 2 rules out a Test Runner left stuck by a previous run.

What does work

• run_tests(mode="EditMode"): 322 tests in 3.1 s, no incident, including right after a hang and restart.
• Entering Play Mode manually: manage_editor(action="play") returns "Entered play mode" and the Editor stays healthy. So Play Mode itself is not the problem — driving it from the Test Runner API is.
• run_tests(clear_stuck: true) returns No running job to clear, so stale job state is not the cause.

Lead (not verified — I did not instrument the bridge)

The hang happens between TestJobManager.StartJob and the first Test Runner callback. futex_do_wait with a frozen log suggests waiting on a lock that is never released — plausibly a synchronisation between the HTTP bridge thread and the Editor main thread at the moment TestRunnerApi triggers the Play Mode transition. The Linux-specific D-Bus GLib-GIO-CRITICAL may be a hint about the environment in which that transition goes wrong.

Impact

Not blocking for everyday use — EditMode covers most of it. It does block anything that needs a measurement in Play Mode: in our case, Frame Debugger based draw-call attribution, and any end-to-end test of frame capture. One test in our suite is marked [Ignore] because of this.

Workaround

None known for PlayMode test runs. For a one-off measurement, manage_editor(action="play") plus manual reading works — but that is not a test.