Subprocess timeout in Python 3.14

Did something change in subprocess in Python 3.14? I’m trying to get the Matplotlib tests to pass, and I see a bunch of errors like

E           subprocess.TimeoutExpired: Command '['/opt/hostedtoolcache/Python/3.14.0-beta.3/x64/bin/python', '-R', '-c', "from matplotlib.tests.test_determinism import _save_figure; _save_figure('', 'pdf')"]' timed out after 60 seconds

in the logs. These are tests that run Python in a subprocess to check that multiple runs don’t change the output. Of course the tests work fine on my Mac, and debugging GHA jobs looks like a pain, but does this ring a bell with anyone?

Hi Jouni! I haven’t spotted anything specific in Python 3.14’s subprocess changes that would cause these timeouts, but it sounds like a GitHub Actions environment issue. GHA might have resource constraints (CPU/IO) slowing down Matplotlib’s subprocesses. Try bumping the timeout (e.g., to 120s) in the test config or disabling resource-heavy tests for GHA. Your Mac runs faster likely due to better local IO. Check Python 3.14’s changelog for subprocess or Matplotlib’s issue tracker—someone might’ve reported this. Let us know if you find anything!

Increasing the timeout to 180s doesn’t help. Weirdly, when I run only the determinism tests (which use subprocesses), they are fine:

But when running all tests, at least some of the determinism tests fail:

So I’m inclined to believe that this is a GHA environment issue: perhaps we use up some kind of burstable resource. But somehow it only happens with Python 3.14 beta builds.

In that last run, it looks like the subprocess possibly didn’t start right, from the logs the (returncode: -9 is suspicious to me):

self = <Popen: returncode: -9 args: ['/opt/hostedtoolcache/Python/3.14.0-beta.3/x64...>
endtime = 935.633342902, orig_timeout = 60, stdout_seq = [], stderr_seq = []
skip_check_and_raise = False

If the subprocess is hanging a tool I’ve found useful when can’t locally debug is faulthandler — Dump the Python traceback — Python 3.13.5 documentation. In particular, can use dump_traceback_later to make it so stack prints during the waiting for timeout.

I think that just means it was killed with SIGKILL, presumably due to the timeout.

Thanks – this was useful! It showed that the subprocess is hanging when it is itself calling another subprocess that is trying to find the version of inkscape installed, and that call does not have a timeout. For whatever reason, the subshell spawned to run inkscape -V is hanging indefinitely, and adding a timeout to that call helps the tests get further.

2 Likes