[Bug]: Exception raised by a signal handler kills the sync dispatcher fiber, every later sync call spins at 100% CPU #3222

Activity

1. gchai commented on Oct 6, 2026

   

   Gabe (gchai)

   on Oct 6, 2026

   More actions

   Confirming this on Playwright 1.63.0 (Python 3.14.6 on macOS arm64; pytest 9.1.1, pytest-timeout 2.4.0, greenlet 3.5.1). We hit it in a Linux CI suite: one pytest worker made no progress for about an hour and then had to be SIGKILLed, and the JUnit report it had written held zero testcases. We have no stack from CI itself, only from local reproductions of the same shape. Some details that may help whoever picks this up:

   1. One SIGINT does not end the process. With the pytest repro from the description, the first SIGINT only breaks the first spin (in test_next). pytest then runs session teardown, where the browser fixture's browser.close() hits the dead dispatcher and spins again; a second SIGINT ends it. A runner that sends one SIGINT and waits a grace period before SIGKILL therefore ends up SIGKILLing. The main-thread stack about 8 seconds after the first SIGINT:

   File ".../playwright/_impl/_sync_base.py", line 113, in _sync
   File ".../playwright/sync_api/_generated.py", line 16537, in close
   File "test_repro.py", line 10, in browser        # browser.close() in the session fixture
   File ".../_pytest/fixtures.py", line 1014, in _teardown_yield_fixture
   File ".../_pytest/runner.py", line 112, in pytest_sessionfinish
   

   2. The alarm does not have to land in a test body. With pytest-timeout's default timeout_func_only = false, the per-test timeout also covers fixture setup. A slow session-scoped fixture that drives its own browser is enough: the first test's timeout fires inside the fixture, and the spin is in the Browser.close() of its finally. A sync call blocked inside an event handler (page.on("console", ...) with a handler that calls page.wait_for_timeout(...)) wedges the same way.

   3. The workaround in the description works. Its snippet shows only the handler, so here is a complete conftest.py that installs it. It replaces pytest-timeout's signal timer; other methods, and non-main threads, fall through to pytest-timeout's own.

   import asyncio
   import contextlib
   import signal
   import threading
   
   import greenlet
   import pytest
   from pytest_timeout import timeout_sigalrm
   
   
   def _root(g):
       while g.parent is not None:
           g = g.parent
       return g
   
   
   def pytest_timeout_set_timer(item, settings):
       if (
           settings.method != "signal"
           or threading.current_thread() is not threading.main_thread()
       ):
           return None  # leave every other case to pytest-timeout
   
       def handler(signum, frame):
           __tracebackhide__ = True
           try:
               timeout_sigalrm(item, settings)  # raises pytest.fail.Exception
           except pytest.fail.Exception as exc:
               current = greenlet.getcurrent()
               root = _root(current)
               if current is root:
                   raise
               # The signal interrupted select() inside the dispatcher fiber; wake the loop,
               # or it resumes waiting with the timeout it was entered with.
               with contextlib.suppress(RuntimeError):
                   asyncio.get_running_loop().call_soon_threadsafe(lambda: None)
               root.throw(exc)
   
       def cancel():
           signal.setitimer(signal.ITIMER_REAL, 0)
           signal.signal(signal.SIGALRM, signal.SIG_DFL)
   
       item.cancel_timeout = cancel
       signal.signal(signal.SIGALRM, handler)
       signal.setitimer(signal.ITIMER_REAL, settings.timeout)
       return True

   On 1.63.0 it turns the repro from the description into 1 failed, 1 passed in 1.2s (test_slow fails with Timeout (>1.0s), test_next passes, teardown completes), and the two variants in (2) behave the same way.

   The call_soon_threadsafe wake matters more than it looks. The interrupted select() resumes with the timeout it was entered with, so without the wake the next call is not sent until the abandoned call finishes. In the repro above that is only the remaining ~4 seconds of wait_for_timeout(5000) (6.9 s total instead of 2.5 s). With wait_for_timeout(60_000) it is a 0%-CPU stall (still running after 25 s) instead of a 100%-CPU spin.

   The abandoned call's task is left pending, so Task exception was never retrieved (a TargetClosedError) may be logged when its page closes in teardown. That was the only side effect we saw.
2. Pavel Feldman (pavelfeldman)

   added a commit that references this issue on Oct 8, 2026

   fix(sync): survive an exception raised by a signal handler during a s…

   ...

   df91ddb
3. Pavel Feldman (pavelfeldman)

   closed this as completedin #3230on Oct 8, 2026