Open godlygeek opened 4 months ago
This seems to happen in conhost/OpenConsole as well. It may be easier to use that first to investigate the issue.
In the vim editor, the same is true
Sorry for the delay. I've debugged this issue now and found that WSL simply stops reading from our input buffer in these situations. As such this is almost assuredly a deadlock in WSL. The default pipe size on Windows is 4KiB and I suspect WSL is waiting for its input pipe to be drained by the shell/application.
@lhecker said he'd look into this a bit. So we put Needs-Attention on it and we'll circle back when he has more info :)
I've realized that the best way to prove that this isn't an issue with either Windows Terminal, conhost, or ConPTY is by testing this issue in https://github.com/mintty/wsltty (which relies on none of those) and it still occurs there.
I'm not 100% certain if this means it's an issue in Python or WSL though as I'm not super familiar with either. But it does show that the issue is not caused by us, from what I can tell.
Let me know if you have any questions! Otherwise, the bot will close the issue in a week. 🙂
I disagree, there's an issue here that's different from what's seen with wsltty. You're right that pasting Frankenstein does cause wsltty to hang as well, but it doesn't deadlock. You can press ctrl-c, and it recovers (albeit some of the clipboard contents wind up being consumed by the shell). This is different from what we see with Windows Terminal: it hangs and can't recover. It's unable to send a signal to the process, and deadlocks such that it must be killed.
Thank you for saying that! I didn't realize that if wsltty doesn't read past 4KiB it may still have a functional Ctrl-C. I thought the two issues are one and the same.
So, I spent some more time investigating this. WSL (under Windows Terminal) sets the input mode to 0x03d8
via SetConsoleMode
. Decoded this means:
0x0008 ENABLE_WINDOW_INPUT
0x0010 ENABLE_MOUSE_INPUT
0x0040 ENABLE_QUICK_EDIT_MODE
0x0080 ENABLE_EXTENDED_FLAGS
0x0100 ENABLE_AUTO_POSITION
0x0200 ENABLE_VIRTUAL_TERMINAL_INPUT
Without ENABLE_PROCESSED_INPUT
(= 0x0001
) we will not translate Ctrl-C (= '\x03'
) to a CTRL_C_EVENT
for SetConsoleCtrlHandler
(= Windows' closest equivalent for SIGINT
). The official WSL bridge is waiting for the UNIX to read from stdin. As long as it's blocked there, it won't read stdin from the terminal either. This means it won't ever see the '\x03'
that is at the end of the stdin buffer.
I tested whether this is a bug in WSL where it does have a SetConsoleCtrlHandler
set up but forgot to set ENABLE_PROCESSED_INPUT
by forcing the flag inside conhost / the terminal. That causes WSL to exit which means it doesn't have SetConsoleCtrlHandler
set up.
You could argue that we should behave differently (please let me know if you have any suggestions!), but it seems like we are behaving "to spec". WSL asks for no input preprocessing and so we don't handle Ctrl-C. I believe the reason this works with wsltty is because it doesn't use the official WSL bridge, but rather https://github.com/Biswa96/wslbridge2 which is probably more robust. From what I can tell, the official WSL bridge needs to be fixed here.
Windows Terminal version
1.20.11381.0
Windows build number
10.0.19045.4412
Other Software
WSL
Steps to reproduce
python3 -c 'print("Paste now:"); import time; time.sleep(10)'
python3
command you pasted in step 2.Expected Behavior
The terminal should remain responsive. Ctrl-C should work. The full pasted text should be displayed.
Actual Behavior
Deadlock. I assume that what's happening here is that Windows Terminal is making blocking write() calls in its paste implementation. If the application doesn't read what's been pasted, or can't keep up, the terminal hangs and becomes totally unresponsive. This was discovered while investigating an issue with the Python 3.13 REPL, but it appears to be a bug in Windows Terminal itself.