gh-160787: Reap the killed child in subprocess.run() on KeyboardInterrupt - #160941

I found that subprocess.run() had a cleanup issue when Ctrl-C (KeyboardInterrupt) occurred. The child process was correctly killed, but it was not being reaped. run() relied on Popen.exit() for cleanup, but exit() intentionally skips waiting for the child during KeyboardInterrupt. As a result, Python could emit a misleading ResourceWarning saying the subprocess was still running even though it had already been terminated.

To fix this, I updated Lib/subprocess.py so that run() explicitly reaps the child process immediately after killing it. I used a bounded wait of up to 1 second to ensure the cleanup happens without violating CPython's requirement that Ctrl-C handling must not block indefinitely.

I also added a regression test, test_run_keyboardinterrupt_reaps_killed_child, in Lib/test/test_subprocess.py. The test simulates a KeyboardInterrupt during subprocess.run() and verifies that the child process has been collected by checking that it receives an exit status. The test fails before the fix and passes afterward.

Finally, I added a NEWS entry documenting the bug fix, while leaving the existing Ctrl-C tests unchanged to ensure no existing behavior was affected.

AI assistance

I used Claude Code (an AI assistant) to investigate and draft this change; I reviewed it and can explain it.

Root cause. On an exception, run() kills the child and relies on Popen.__exit__() to wait. After a KeyboardInterrupt, __exit__() skips the wait once the SIGINT grace period was used (_sigint_wait_secs == 0), so the killed child is never reaped and __del__() warns before it polls.

Fix. run() reaps the killed child with process._wait(timeout=1). A plain process.wait() would block indefinitely and break the bpo-25942 guarantee that test_run_keyboardinterrupt_no_kill checks ("no open-ended wait() after the first"). _wait() is used rather than wait() because wait() adds its own SIGINT grace period, which no longer applies to a child that was just killed. __exit__() uses _wait() the same way.

Tests. New test_run_keyboardinterrupt_reaps_killed_child: it fails without the change ("unexpectedly None") and passes with it. The existing *keyboardinterrupt* tests pass unchanged. A real-signal repro (timer sends SIGINT to the parent, start_new_session=True child) emitted the ResourceWarning 3/3 times before the fix and 0/5 after.

./python -m test test_subprocess -m "*keyboardinterrupt*"   # 4 tests OK
./python -m test test_subprocess -j4                         # 372 run, OK
make patchcheck                                              # NEWS entry present, clean

Tested on Linux (WSL2), CPython main at ef1fce0 (3.16.0a1+).

🤖 Generated with Claude Code

• Issue: subprocess.run() can warn that a child is still running after killing it on Ctrl-C #160787