_kill_process() guards the join() of the killed child with a SIGALRM so that a blocked waitpid() becomes a readable error instead of a hang. The alarm has been a literal 10 seconds since it was added in 2013 (cc5c728), so on a build slow enough that reaping the child legitimately takes longer than that, it fires on a healthy run and fails the test. That is what happened on the UBSan job of 57594aa (traceback in the issue): the alarm interrupted os.waitpid() itself.

test.support.LONG_TIMEOUT is documented for this exact purpose, "Timeout in seconds to detect when a test hangs [...] It should not be used to mark a test as failed if the test takes 'too long'", and regrtest scales it from --timeout for slow workers. The SHORT_TIMEOUT docs point the same way: "If a test using SHORT_TIMEOUT starts to fail randomly on slow buildbots, use LONG_TIMEOUT instead." _kill_process() already uses support.SHORT_TIMEOUT a few lines above for its event wait. math.ceil() keeps the alarm from being cancelled outright if a very short --timeout scales the value below one second.

Four tests go through this helper, in every start-method variant: test_interrupt, test_interrupt_no_handler, test_terminate and test_kill.

Verified by making the child slow to die (a SIGINT handler that sleeps 12 seconds), which is what a loaded machine looks like from the parent's side, and running the real test_interrupt. On Linux with the fork start method, the configuration that failed on CI, and on macOS with spawn:

Without the injected delay, test_multiprocessing_spawn, test_multiprocessing_forkserver, test_multiprocessing_fork, test_multiprocessing_main_handling and test_concurrent_futures pass (1427 tests).

• Issue: _test_multiprocessing._kill_process() uses a fixed 10 s alarm, failing on slow builds #157184