[issue42962] Windows: SystemError during os.kill(..., signal.CTRL_C_EVENT)

[Eryk Sun]

Eryk Sun <eryksun at gmail.com> added the comment:

> That's what Lib/test/win_console_handler.py:39 does. 

No, that script is currently broken.

SetConsoleCtrlHandler(None, False) clears the Ctrl+C ignore flag in the PEB ProcessParameters, which is normally inherited by child processes. But using the CREATE_NEW_PROCESS_GROUP creation flag always causes Ctrl+C to be initially ignored in the process. The intent is to make it a 'background' process by default, to support CMD's `start /b` option.

Win32KillTests in Lib/test/test_os.py incorrectly assumes it only has to enable Ctrl+C in the parent process. win_console_handler.py incorrectly assumes it does not have to call SetConsoleCtrlHandler(None, False). This is why test_CTRL_C_EVENT() is currently being skipped. To fix it, win_console_handler.py needs to call SetConsoleCtrlHandler(None, False).

> Isn't that what PyConfig.install_signal_handlers is supposed to do?

The C runtime's signal() function does not clear the Ctrl+C ignore flag when a SIGINT handler is set. I think Python should. It's expected behavior for POSIX compatibility.

>    with self.assertRaises(KeyboardInterrupt):
>        os.kill(os.getpid(), SIG)

Unless you know the current process was created in a new process group, it is not correct to call os.kill(os.getpid(), signal.CTRL_C_EVENT). You'd be better off using os.kill(0, signal.CTRL_C_EVENT) and ensuring that Ctrl+C is temporarily ignored in the parent process, if that's in your control. Also, Python 3.8 added raise_signal(), which calls C raise(), so a more reliable way to test just the signal handler is to call signal.raise_signal(signal.SIGINT). This also eliminates needing to synchronize with the console control thread.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42962>
_______________________________________