[ViperJuice]

What failed

Four test (3.x) jobs ended with exit 139 (SIGSEGV), on 3.11 and 3.12:

• 3.11: 110206935522, 110199067410 and 110194147466
• 3.12: 110224907585

gh run view --log truncates the step log. The full REST job logs show the same thing in every job. The test was test_version_pin.py::test_the_invalid_pin_text_is_true_with_sources_before_and_after_it. Timeout (0:02:00)! appears, a thread dump starts in yaml/scanner.py and is cut off mid-line, and the job exits with 139. Main's own runs hit the same 120 s dump on 3.10, 3.11 and 3.12 and survived it, with jobs taking up to 24:36 of the 25-minute cap.

Root cause (the class)

faulthandler_timeout = 120 sat below the pytest-timeout kill (700 s). faulthandler's C watchdog dumps every thread without holding the GIL while the main thread keeps running. Any test that was slow but still running and crossed 120 s got its moving frame chain walked from another thread, and that can segfault. The tests from #323 were simply the first to cross 120 s.

They got there for two reasons:

• The test itself: each test re-parses the 78 KB shipped manifest in pure-Python YAML, 432 times in total.
• A pre-existing handler leak: pmcp.cli.setup_logging adds two root-logger handlers on every call, and nothing removed them. After tests/test_cli.py there were 90, and every later WARNING fanned out to all of them.

Fix

1. Put the GIL-free dump above the kill, and make it fail closed (pyproject.toml).
   • timeout = 700 (signal method) is now the first thread dump and the kill. Its handler runs under the GIL, and the failed item cancels the faulthandler timer.
   • faulthandler_timeout = 720 with faulthandler_exit_on_timeout = true is the last resort. It only fires for a thread the kill could not reach, such as one stuck in C or holding the GIL, and then it dumps and exits. So even that hang ends red with a stack, not in the silent 25-minute cancel that tests/runtime: TestRemoteEmitterReachesDispatch (SSE) intermittently hangs in CI until the 25-minute job timeout #200 removed.
   • The 60 s async watchdog is unchanged. It runs in Python under the GIL.
   • The new ladder is 60 s, then 700 s, then 720 s, then 25 min. It is documented in pyproject.toml and tests/runtime/_hang_watchdog.py.
2. Tests for the ladder (tests/runtime/test_hang_diagnostics.py). These replace the old "zero-risk, run continues" test.
   • A subprocess where a slow test is still running Python: pytest-timeout fails it, faulthandler never fires, and the session continues.
   • A subprocess where SIGALRM is blocked, so the kill cannot land: faulthandler dumps, the process exits non-zero, and the sentinel test never runs.
   • The ini invariant is now 0 < timeout < faulthandler_timeout < 25 min, plus exit-on-timeout and the signal method.
   • Mutation checks: with the old ordering, faulthandler fires on the slow test. With exit-on-timeout turned off, the run "passes" past the wedge. The new tests catch both.
3. Stop the root-logger leak (tests/conftest.py). A new autouse fixture removes and closes any root-logger handlers a test added, and restores the level. pytest's own capture handlers are left alone.
   • Running test_cli.py, then test_scoped_advisor_audit.py, then the two precedence tests: 90 handlers before and 2 after, and 68.4 s before and 18.5 s after.
   • No test depended on the leaked handlers. The full suite passes, and --- Logging error --- appears 0 times.
4. Memoise the shipped-manifest parse in the two exhaustive tests (kept from round 1). Each distinct YAML text is parsed for real once. Each caller gets a fresh copy through a pickle round trip, and parse errors are not cached. A merge-order bug in the loader still fails both tests.

This changes no src/ code and no behaviour, so there is no CHANGELOG entry.

Evidence

• Gates: ruff check src/ tests/ passes, ruff format --check src/ tests/ reports 171 files already formatted, and mypy src/pmcp reports no issues in 52 files.
• Local run: the full CI command on 3.11.16 under coverage gave 4887 passed and 89.44% coverage, with 0 Timeout (0: lines. It took 11:25, down from 13:33 for round 1.
• CI on 9401f06: all checks green. From the full REST logs:

job	pytest time	job time	Timeout (0: dumps	the two precedence tests
3.10	9:51	10:06	0	0.9 s + 2.5 s
3.11	14:56	15:17	0	1.5 s + 3.9 s
3.12	12:29	12:50	0	1.4 s + 3.1 s

For comparison, main's d5a3cda re-run took 23:49 of pytest time on 3.11, with a 120 s dump on 3.10 and 3.11.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RiabTgWZRfuqiUQ9siEegF