This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eryksun
Recipients William.Schwartz, eryksun, ncoghlan, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
Date 2021-01-19.09:05:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> I just reported it because the SystemError indicates that a C-API function
> was returning non-NULL even after PyErr_Occurred() returns true

Fixing the SystemError should be simple. Just clear an existing error if TerminateProcess() succeeds. 

> Windows Command shell inside *Command Prompt* (not Windows Terminal):

The cmd.exe shell (aka command prompt or command interpreter) is a console client application like python.exe, which attaches to a console session that's hosted by conhost.exe or openconsole.exe. The host also implements the console UI, unless it's executed in pseudoconsole mode (e.g. a tab in Windows Terminal). 

> C:\Users\wksch>python -c"import os, signal, time; os.kill(os.getpid(),
> signal.CTRL_C_EVENT); time.sleep(1)"

The above kill() call is implemented by calling GenerateConsoleCtrlEvent() to send the cancel event to clients of the console session that are members of the process group, os.getpid(). But there is no such group since Python isn't executed as a new process group. GenerateConsoleCtrlEvent() should fail with an invalid parameter error, and kill() should fall back on TerminateProcess(). But GenerateConsoleCtrlEvent() has a bug in cases like this that causes it to behave as if it were passed group ID 0 (i.e. all processes in the console session). If not for the bug in the console, this example would also raise SystemError.

> In the Windows Command shell inside *Windows Terminal*

The misbehavior is different in a pseudoconsole session, which is probably due to an unrelated bug that's affecting the expected bug. Other than Windows Terminal, another simple way to get a pseudoconsole session is to run cmd.exe from WSL. (The UI will be in the same console as WSL, but cmd.exe will actually be attached to a pseudoconsole session that's hosted by a headless instance of conhost.exe.) In pseudoconsole mode, the console will broadcast the control event only after a key such as enter or escape is pressed, which is obviously a bug in the console's input event loop. It's still a case of GenerateConsoleCtrlEvent() nominally succeeding with buggy behavior where it should fail.
Date User Action Args
2021-01-19 09:05:57eryksunsetrecipients: + eryksun, paul.moore, ncoghlan, vstinner, tim.golden, zach.ware, William.Schwartz, steve.dower
2021-01-19 09:05:56eryksunsetmessageid: <>
2021-01-19 09:05:56eryksunlinkissue42962 messages
2021-01-19 09:05:56eryksuncreate