Terminal Keyboard Inputs not being accepted

[yousefabuz17]

Bug: Python Interpreter Extension

------------------------------------------------------------------------------------------------->

Steps to cause the bug to occur

1. Latest version of python contains this bug where if you type a code simple like:
   age = input("Enter age: )
   print(age)

In the terminal when you type in a number or anything and then click enter, it would not accept the user input and took me awhile to realize its because of the new update.

Actual behavior

Terminal not accepting user inputs

Expected behavior

Terminal needs to accept user inputs in order to run the full code if necessary.

Solution:
Downgrade the python interpreter from 2020.8.101144 to one below it.

[dongchenyu163]

The same issue at the Ubuntu 18.04.3. But windows10 not.
The python debugger will stucked because it can not receive any input while input() function is executing.
Moreover, the input characters will not send to the python debugger but sending to the terminal after the python debugger is stopped.

Test program is below:

res = input("Enter something:")  # Program stuck here. Stop the debugger.
print(res)

[yousefabuz17]

Yes luckily downgrading the python interpreter solved this annoying issue. I had to uninstall VSCode, remove all extensions just to find out all I had to do was downgrade the latest python extension lol.

[karthiknadig]

@yousefabuz17 @dongchenyu163 Try adding "redirectOutput": true to your launch.json debug configuration, see #296 (comment). This was changed recently to allow better control of IO redirection.

@int19h we may need to handle this based on console setting. We should also change the name of the setting to better reflect that it redirects input and output streams.

[yousefabuz17]

@karthiknadig ok I will definitely try that. Thanks for the feedback. I'm hoping a new update will be released soon so no one else will have this issue.

[fabioz]

I still haven't investigated why that happens, but I can confirm that I can reproduce it on Ubuntu while it still works on Windows.

I tried just putting the stdin patching in place again, but it didn't seem to make any difference (so, it's probably related to something else).

[McCarthyCode]

This appears to be a Linux issue. I'm running Arch 5.7.8 and am experiencing this problem.

[yousefabuz17]

@mattmc318 you think so? I believe it's the Python Extension it's self that's the issue ever since the new update a couple days ago. Downgrading it obviously fixed the issue but it has to do with whatever they changed in the new update. @karthiknadig mentioned to add redirectOutput in launch.json while debugging but didn't work for me so.

I'm also running this with Visual Studio Code on a Mac latest version.

[McCarthyCode]

@yousefabuz17 Maybe not, then. I was just basing that assessment off of other comments. I'm new here, lol. It seems to work on Windows, but that could be just because it wasn't updated, or for any other reason besides it being platform-specific.

[karthiknadig]

One of the things that changed with the new version of the extension was the debugger version. We updated the extension to the latest debugger version. So when you downgrade the extension, you are automatically downgrading the debugger.

[zlcnup]

@karthiknadig "redirectOutput": true in launch.json didn't work for me. I encountered this issue after updating VSCODE(1.48.0) and Python extension(2020.8.101144) on Win10.

[yousefabuz17]

@zlcnup yea that didn't work for me either. I'm just waiting till a solution gets released or they simply update the python extension again

[int19h]

It's the reverse - "redirectOutput": true also redirects stdin, so it might break some libraries that rely on sys.stdin being exactly the type that Python normally makes it be. Conversely, "redirectOutput": false is what you want for minimum interference.

Also, the default for that setting already depends on "console" - it's only true by default if that's set to "internalConsole", and false otherwise.

[int19h]

This is a regression caused by 57ec4c4 - using a separate process group breaks terminal I/O, even though stdin is still propagated correctly. Need to revert that part of the change, and come up with a different way to manage the process tree.

[zlcnup]

I re-test on pure local Win10 using "redirectOutput": both true and false, and debug input() working normally. But it doesn't work on vscode-server by Remote-SSH DEBUG manner (remote machine: Ubuntu16.04, local machine: Win10). Both machines have the same Python Extension version. Run *.py directly in the integrated terminal (not DEBUG), and the input() works fine.

[conkerkh]

Regardless "redirectOutput" settings "input" is broken on macOS Catalina and probably other versions as well.

[fabioz]

@int19h as a note, there's code to kill a process tree at https://github.com/microsoft/debugpy/blob/master/src/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_api.py#L975 (I don't think pydevd is even imported on the no-debug mode, so, probably the alternative so that there are no deps is copying that code and adapt it to kill a process tree -- although if pydevd can be imported, it should be possible to refactor the code a bit to have an API to kill a process tree given a pid).

[fabioz]

For anyone arriving here, there are currently no workarounds other then downgrading the python extension to a version below 2020.8.101144, which is the one that contains the debugger updates which introduced this issue.

This issue currently affects input() on Linux and Mac (including the case for Remote-SSH into those), while Windows appears to be unaffected.

This is a high-priority issue and it's already being worked on.

[int19h]

@fabioz Yep, the adapter never imports pydevd at all, deliberately so.

My other concern with that approach is that on Unix, walking the process tree manually and killing PIDs can potentially race with process termination & creation, so you can end up killing unrelated processes that just happened to reuse PIDs. It's exacerbated in "launch" cleanup scenario, because that one is often a race between the process terminating normally, and the launcher killing it.

And while we can manage PID lifetime for the immediate debuggee (by not doing waitpid() until it's safe for PID to be reused), we can't manage it for debuggee's subprocesses, since the code that might or might not waitpid() on them is not under our control.

[int19h]

The hacky workaround is to remove this bit in debugpy that's bundled with the extension:

debugpy/src/debugpy/launcher/debuggee.py

Lines 63 to 66 in 57ec4c4

	if sys.platform != "win32":
	# Start the debuggee in a new process group, so that the launcher can kill
	# the entire process tree later.
	kwargs.update(preexec_fn=os.setpgrp)

(In multi-process scenarios, this will also prevent subprocesses from being cleaned up in some cases, esp. if using Start without Debugging.)

[SaadiSave]

So when will this fix be released?

[yousefabuz17]

@SaadiSave hopefully soon but honestly I have no problem in using the roll back version. Simply downgrade python for now. Still works very fast with no issues

[SaadiSave]

I tried that. The API appears to be broken. It cannot find the old version. Could you send the link that you used to download the vsix for the old version?
Thank you.

[karthiknadig]

You can do it from VS Code, click on the gear icon for the extension and select "install another version":

If you want to manually find and install older versions of the extension they can be found here: https://github.com/microsoft/vscode-python/releases

[SaadiSave]

Thank you

[yousefabuz17]

This may solve this issue for the mean time. I have not tested it out yet as it was just mentioned. Thought I'd share it to anyone here. Hope it works.

https://github.com/microsoft/vscode-python/issues/13536