Debuger doesn't work anymore

[tollvam]

Environment data

• VS Code version: 1.43.2
• OS and version: macOS 10.14.6
• Python version (& distribution if applicable, e.g. Anaconda): 3.7.4, Anaconda

Expected behaviour

• Debugger working fine (It worked well before i install python3.7 but i have a doubt if the last time was before or after 3.7, I had 3.6 before).

Actual behaviour

But files not found are here (the third one is the one from where i launch the debugger)

Steps to reproduce:

1. Launch Debugger

[tamckenna]

I had the same exact issue this morning. Using Python 3.7.7 on the same VS Code version. I'm running on Catalina though.

I had a .bashrc alias causing the issue. Specifically: alias env='env | sort
Once I commented it out the debugger worked completely fine. So I have renamed the alias to senv to fix this issue. I'm guessing somehow the debugger is referencing that alias somehow. If that isn't your issue I'd recommend debugging your startup scripts to see if they are causing the issue.

[tollvam]

@tamckenna thanks for your answer. Would you mind to do a step by step on how to fix it ? I'm not sure how to reproduce what you did, thanks !

[tamckenna]

I commented out my entire .bashrc file and then reopened VSCode and tried debugging again, which worked. I then knew that it was something in my bashrc file. Widdled it down to the env alias. So comment out your startup scripts ie. .bashrc, .bash_profile, .zshrc, et cetera. To see if that is the issue.

[tollvam]

I don't have one of those hidden file in ~/

[tamckenna]

Another way you can verify that the user setup is the issue is by creating a new user in macOS and trying the debugger under that user.

If that’s not the issue it could be your vscode install. To verify that is the issue you could use a portable instance of vscode and only install the python debugger and see if that works. https://code.visualstudio.com/docs/editor/portable

[tollvam]

So it works with a new user, but as i can't find the files you mentioned, how could i resolve that for my user ? thanks

[int19h]

Try this in the terminal:

type env

if it's an alias, it will tell you what it expands into.

[kagesenshi]

Facing this problem too with 2020.3.71113 (31 March 2020) on Fedora Linux. Debugger toolbar appear for a while and then dissappear silently without error message when trying to start.

env is /usr/bin/env and not an alias.

Could there be some text parsing being done on env command stdout? and a slight variation of what env outputs fails this?

All my team members, mostly of which are on stock Fedora installation, are reporting same issue.

following is the the output of env, in case it helps

[izhar@localhost validators]$ type env
env is /usr/bin/env
[izhar@localhost validators]$ env
SHELL=/bin/bash
SESSION_MANAGER=local/unix:@/tmp/.ICE-unix/6626,unix/unix:/tmp/.ICE-unix/6626
COLORTERM=truecolor
HISTCONTROL=ignoredups
XDG_MENU_PREFIX=gnome-
TERM_PROGRAM_VERSION=1.44.0-insider
HOSTNAME=localhost.localdomain
HISTSIZE=1000
GUESTFISH_OUTPUT=\e[0m
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
MODULES_LMCONFLICT=python-sphinx/python3-sphinx&python-sphinx
_LMFILES__modshare=/usr/share/modulefiles/python-sphinx/python3-sphinx:1
XMODIFIERS=@im=ibus
DESKTOP_SESSION=gnome-xorg
LC_MONETARY=en_GB.UTF-8
SSH_AGENT_PID=2865
NO_AT_BRIDGE=1
XDG_SEAT=seat0
ENV=/usr/share/Modules/init/profile.sh
PWD=/home/izhar/Devel/dqmt_deploy/dev/dqmt/scripts/validators
XDG_SESSION_DESKTOP=gnome-xorg
LOGNAME=izhar
XDG_SESSION_TYPE=x11
MODULESHOME=/usr/share/Modules
MANPATH=:
XAUTHORITY=/run/user/1000/gdm/Xauthority
GUESTFISH_RESTORE=\e[0m
GJS_DEBUG_TOPICS=JS ERROR;JS LOG
WINDOWPATH=3
GDM_LANG=en_US.UTF-8
HOME=/home/izhar
USERNAME=izhar
LANG=en_US.UTF-8
LC_PAPER=en_GB.UTF-8
LS_COLORS=rs=0:di=38;5;33:ln=38;5;51:mh=00:pi=40;38;5;11:so=38;5;13:do=38;5;5:bd=48;5;232;38;5;11:cd=48;5;232;38;5;3:or=48;5;232;38;5;9:mi=01;37;41:su=48;5;196;38;5;15:sg=48;5;11;38;5;16:ca=48;5;196;38;5;226:tw=48;5;10;38;5;16:ow=48;5;10;38;5;21:st=48;5;21;38;5;15:ex=38;5;40:*.tar=38;5;9:*.tgz=38;5;9:*.arc=38;5;9:*.arj=38;5;9:*.taz=38;5;9:*.lha=38;5;9:*.lz4=38;5;9:*.lzh=38;5;9:*.lzma=38;5;9:*.tlz=38;5;9:*.txz=38;5;9:*.tzo=38;5;9:*.t7z=38;5;9:*.zip=38;5;9:*.z=38;5;9:*.dz=38;5;9:*.gz=38;5;9:*.lrz=38;5;9:*.lz=38;5;9:*.lzo=38;5;9:*.xz=38;5;9:*.zst=38;5;9:*.tzst=38;5;9:*.bz2=38;5;9:*.bz=38;5;9:*.tbz=38;5;9:*.tbz2=38;5;9:*.tz=38;5;9:*.deb=38;5;9:*.rpm=38;5;9:*.jar=38;5;9:*.war=38;5;9:*.ear=38;5;9:*.sar=38;5;9:*.rar=38;5;9:*.alz=38;5;9:*.ace=38;5;9:*.zoo=38;5;9:*.cpio=38;5;9:*.7z=38;5;9:*.rz=38;5;9:*.cab=38;5;9:*.wim=38;5;9:*.swm=38;5;9:*.dwm=38;5;9:*.esd=38;5;9:*.jpg=38;5;13:*.jpeg=38;5;13:*.mjpg=38;5;13:*.mjpeg=38;5;13:*.gif=38;5;13:*.bmp=38;5;13:*.pbm=38;5;13:*.pgm=38;5;13:*.ppm=38;5;13:*.tga=38;5;13:*.xbm=38;5;13:*.xpm=38;5;13:*.tif=38;5;13:*.tiff=38;5;13:*.png=38;5;13:*.svg=38;5;13:*.svgz=38;5;13:*.mng=38;5;13:*.pcx=38;5;13:*.mov=38;5;13:*.mpg=38;5;13:*.mpeg=38;5;13:*.m2v=38;5;13:*.mkv=38;5;13:*.webm=38;5;13:*.ogm=38;5;13:*.mp4=38;5;13:*.m4v=38;5;13:*.mp4v=38;5;13:*.vob=38;5;13:*.qt=38;5;13:*.nuv=38;5;13:*.wmv=38;5;13:*.asf=38;5;13:*.rm=38;5;13:*.rmvb=38;5;13:*.flc=38;5;13:*.avi=38;5;13:*.fli=38;5;13:*.flv=38;5;13:*.gl=38;5;13:*.dl=38;5;13:*.xcf=38;5;13:*.xwd=38;5;13:*.yuv=38;5;13:*.cgm=38;5;13:*.emf=38;5;13:*.ogv=38;5;13:*.ogx=38;5;13:*.aac=38;5;45:*.au=38;5;45:*.flac=38;5;45:*.m4a=38;5;45:*.mid=38;5;45:*.midi=38;5;45:*.mka=38;5;45:*.mp3=38;5;45:*.mpc=38;5;45:*.ogg=38;5;45:*.ra=38;5;45:*.wav=38;5;45:*.oga=38;5;45:*.opus=38;5;45:*.spx=38;5;45:*.xspf=38;5;45:
XDG_CURRENT_DESKTOP=GNOME
GUESTFISH_PS1=\[\e[1;32m\]><fs>\[\e[0;31m\] 
CHROME_DESKTOP=code-insiders-url-handler.desktop
GJS_DEBUG_OUTPUT=stderr
PATH_modshare=/usr/sbin:1:/opt/cdap/cli/bin:1:/usr/bin:1:/usr/condabin:1:/usr/local/sbin:1:/usr/libexec/python3-sphinx:1:/usr/share/Modules/bin:1:/usr/local/bin:1
MODULEPATH_modshare=/usr/share/modulefiles:1:/usr/share/Modules/modulefiles:1:/etc/modulefiles:1
XDG_SESSION_CLASS=user
LOADEDMODULES_modshare=python-sphinx/python3-sphinx:1
TERM=xterm-256color
LESSOPEN=||/usr/bin/lesspipe.sh %s
USER=izhar
CONDA_SHLVL=0
MODULES_RUN_QUARANTINE=LD_LIBRARY_PATH
LOADEDMODULES=python-sphinx/python3-sphinx
MODULES_LMCONFLICT_modshare=python-sphinx/python3-sphinx&python-sphinx:1
DISPLAY=:1
SHLVL=1
BASH_ENV=/usr/share/Modules/init/bash
GUESTFISH_INIT=\e[1;34m
QT_IM_MODULE=ibus
LC_MEASUREMENT=en_GB.UTF-8
XDG_VTNR=3
XDG_SESSION_ID=12427
XDG_RUNTIME_DIR=/run/user/1000
LC_TIME=en_GB.UTF-8
XDG_DATA_DIRS=/home/izhar/.local/share/flatpak/exports/share/:/var/lib/flatpak/exports/share/:/usr/local/share/:/usr/share/
PATH=/home/izhar/.local/bin:/home/izhar/bin:/home/izhar/.local/bin:/home/izhar/bin:/usr/share/Modules/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/opt/cdap/cli/bin:/opt/cdap/cli/bin:/opt/cdap/cli/bin
MODULEPATH=/etc/scl/modulefiles:/etc/scl/modulefiles:/etc/scl/modulefiles:/etc/scl/modulefiles:/usr/share/Modules/modulefiles:/etc/modulefiles:/usr/share/modulefiles
GDMSESSION=gnome-xorg
_LMFILES_=/usr/share/modulefiles/python-sphinx/python3-sphinx
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
MAIL=/var/spool/mail/izhar
GIO_LAUNCHED_DESKTOP_FILE_PID=7722
GIO_LAUNCHED_DESKTOP_FILE=/usr/share/applications/code-insiders.desktop
LC_NUMERIC=en_GB.UTF-8
MODULES_CMD=/usr/share/Modules/libexec/modulecmd.tcl
TERM_PROGRAM=vscode
BASH_FUNC_switchml%%=() {  typeset swfound=1;
 if [ "${MODULES_USE_COMPAT_VERSION:-0}" = '1' ]; then
 typeset swname='main';
 if [ -e /usr/share/Modules/libexec/modulecmd.tcl ]; then
 typeset swfound=0;
 unset MODULES_USE_COMPAT_VERSION;
 fi;
 else
 typeset swname='compatibility';
 if [ -e /usr/share/Modules/libexec/modulecmd-compat ]; then
 typeset swfound=0;
 MODULES_USE_COMPAT_VERSION=1;
 export MODULES_USE_COMPAT_VERSION;
 fi;
 fi;
 if [ $swfound -eq 0 ]; then
 echo "Switching to Modules $swname version";
 source /usr/share/Modules/init/bash;
 else
 echo "Cannot switch to Modules $swname version, command not found";
 return 1;
 fi
}
BASH_FUNC_module%%=() {  _module_raw "$@" 2>&1
}
BASH_FUNC_scl%%=() {  if [ "$1" = "load" -o "$1" = "unload" ]; then
 eval "module $@";
 else
 /usr/bin/scl "$@";
 fi
}
BASH_FUNC__module_raw%%=() {  unset _mlshdbg;
 if [ "${MODULES_SILENT_SHELL_DEBUG:-0}" = '1' ]; then
 case "$-" in 
 *v*x*)
 set +vx;
 _mlshdbg='vx'
 ;;
 *v*)
 set +v;
 _mlshdbg='v'
 ;;
 *x*)
 set +x;
 _mlshdbg='x'
 ;;
 *)
 _mlshdbg=''
 ;;
 esac;
 fi;
 unset _mlre _mlIFS;
 if [ -n "${IFS+x}" ]; then
 _mlIFS=$IFS;
 fi;
 IFS=' ';
 for _mlv in ${MODULES_RUN_QUARANTINE:-};
 do
 if [ "${_mlv}" = "${_mlv##*[!A-Za-z0-9_]}" -a "${_mlv}" = "${_mlv#[0-9]}" ]; then
 if [ -n "`eval 'echo ${'$_mlv'+x}'`" ]; then
 _mlre="${_mlre:-}${_mlv}_modquar='`eval 'echo ${'$_mlv'}'`' ";
 fi;
 _mlrv="MODULES_RUNENV_${_mlv}";
 _mlre="${_mlre:-}${_mlv}='`eval 'echo ${'$_mlrv':-}'`' ";
 fi;
 done;
 if [ -n "${_mlre:-}" ]; then
 eval `eval ${_mlre}/usr/bin/tclsh /usr/share/Modules/libexec/modulecmd.tcl bash '"$@"'`;
 else
 eval `/usr/bin/tclsh /usr/share/Modules/libexec/modulecmd.tcl bash "$@"`;
 fi;
 _mlstatus=$?;
 if [ -n "${_mlIFS+x}" ]; then
 IFS=$_mlIFS;
 else
 unset IFS;
 fi;
 unset _mlre _mlv _mlrv _mlIFS;
 if [ -n "${_mlshdbg:-}" ]; then
 set -$_mlshdbg;
 fi;
 unset _mlshdbg;
 return $_mlstatus
}
_=/usr/bin/env
OLDPWD=/home/izhar/Devel/dqmt_deploy/dev/dqmt/scripts

[int19h]

env is not used to retrieve any values, it's used to start the debugger launcher stub and pass some environment variables to it.

Can you show the terminal output when you try to launch and it fails? Does it have any conda activate stuff in it?

[tollvam]

same here, env is /usr/bin/env

[kagesenshi]

There are no output from any terminal .. the debugger toolbar simply appear for a while, and then quits. Attached is a screencast which is using "internalConsole". Similar behavior happens with "integratedTerminal" and "externalTerminal":

Screencast from 02-04-20 21:13:44.zip

[int19h]

@kagesenshi The .webm file appears to be corrupted, and won't play.

That said, if it doesn't open the terminal at all even when you're using "integratedTerminal", then it's a different issue. My guess would be microsoft/debugpy#87, since it has symptoms very similar to what you describe. Try the workarounds described in the comments there - if it still doesn't work for you, then please file a new issue.

[tollvam]

env is not used to retrieve any values, it's used to start the debugger launcher stub and pass some environment variables to it.

Can you show the terminal output when you try to launch and it fails? Does it have any conda activate stuff in it?

@int19h didn't see the second part of your answer, there is "conda activate base" in the terminal output as you can check on the first post, what does this mean ? thx

[int19h]

@tollvam Yep, I've noticed it in your screenshots - was trying to figure out if other reports are about the same issue.

Can you try activating your environment manually in a terminal outside of VSCode, and then starting VSCode from that activated terminal?

[tollvam]

Sorry but could you just explain how to do this ? Thanks !

[int19h]

Since it's Anaconda, you should follow their instructions for activation:
https://docs.conda.io/projects/conda/en/latest/user-guide/tasks/manage-environments.html#activating-an-environment

Once the command line prompts indicates successful activation, you should be able to launch VSCode from it by running code.

[tollvam]

Well apparently by default when i launch a terminal outside VSC i'm already in a environnement, so i deactivated it and activated it but code doesn't work as you can see below :

`Last login: Thu Apr 23 12:48:08 on ttys000
(base) leMacbookPro:~ thomas$ conda deactivate
leMacbookPro:~ thomas$ conda info --envs
# conda environments:
#
base * /Users/thomas/opt/anaconda3

leMacbookPro:~ thomas$ conda activate base
(base) leMacbookPro:~ thomas$ code
-bash: code: command not found`

[tollvam]

Nothing changed with the VSC update to 1.45

[int19h]

Sorry, I missed your earlier reply!

If de/re-activating an environment in a terminal outside of VSCode means that code becomes an unknown command, that means that it's mucking around with your PATH somehow and breaking things. It sounds like there's something very wrong with your Conda installation itself - you might want to file a bug in their own repo, but for starters, I'd try a clean re-install (including re-creating the environment).

You can try to work around the error that you're seeing in the terminal by using a full path to the code binary - use which code in the terminal where it can find it to get that path. But I suspect that things will just break further down the line... this just isn't normal behavior for a Conda env, whether VSCode is in the picture or not.

[tollvam]

I've managed to make "code" works via https://stackoverflow.com/questions/29955500/code-not-working-in-command-line-for-visual-studio-code-on-osx-mac
Then i've launched vsc via the command "code" from the terminal and try to debug a file but same error.
I also did a clean install of anaconda / python.

[int19h]

Does env work for you if you do it in a manually activated conda terminal (i.e. with VSCode completely out of the picture)? i.e. if you do:

$ conda activate base
$ env

[tollvam]

Yes it does

$ env
TERM_PROGRAM=Apple_Terminal
SHELL=/bin/bash
TERM=xterm-256color
TMPDIR=/var/folders/v3/tmrdqb7j52n5v0bj0_l_d2dm0000gn/T/
CONDA_SHLVL=1
Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.cTEgAXW7EX/Render
CONDA_PROMPT_MODIFIER=(base) 
TERM_PROGRAM_VERSION=421.2
TERM_SESSION_ID=ED796EE2-0E4C-42A6-B1F5-A400CC5BFBA7
USER=thomas
CONDA_EXE=/Users/thomas/opt/anaconda3/bin/conda
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.PEslCHW4FJ/Listeners
_CE_CONDA=
PATH=/Users/thomas/opt/anaconda3/bin:/Users/thomas/opt/anaconda3/condabin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
CONDA_PREFIX=/Users/thomas/opt/anaconda3
PWD=/Users/thomas
LANG=fr_FR.UTF-8
XPC_FLAGS=0x0
_CE_M=
XPC_SERVICE_NAME=0
SHLVL=1
HOME=/Users/thomas
CONDA_PYTHON_EXE=/Users/thomas/opt/anaconda3/bin/python
LOGNAME=thomas
CONDA_DEFAULT_ENV=base
DISPLAY=/private/tmp/com.apple.launchd.4SiSjSvs1Z/org.macosforge.xquartz:0
_=/usr/bin/env

[int19h]

But it fails with the same error message if you manually use it in the terminal inside VSCode?

[tollvam]

Not it works also, it fails when i launch the debugger with the error message i put in the first post

[int19h]

When you start debugging, is it still trying to do conda activate in the terminal first (despite you having activated it before starting VSCode), and only then env ...?

[tollvam]

yes twice as you can see below, it's the same error code than in the print screen

bash-3.2$ source /Users/thomas/opt/anaconda3/bin/activate
bash: dirname: No such file or directory
bash: dirname: No such file or directory
 env /Users/thomas/opt/anaconda3/bin/python /Users/thomas/.vscode/extensions/ms-python.python-2020.5.86806/pythonFiles/lib/python/debugpy/wheels/debugpy/launcher 50500 -- "/Users/thomas/Desktop/Tom/Prog/Python/Trading Bot/maintenance.py" 
conda activate base
(base) bash-3.2$  env /Users/thomas/opt/anaconda3/bin/python /Users/thomas/.vscode/extensions/ms-python.python-2020.5.86806/pythonFiles/lib/python/debugpy/wheels/debugpy/launcher 50500 -- "/Users/thomas/Desktop/Tom/Prog/Python/Trading Bot/maintenance.py" 
bash: env: command not found
(base) bash-3.2$ conda activate base
bash: dirname: command not found
bash: dirname: command not found
(base) bash-3.2$ 

[int19h]

Alright, I think this is basically just another manifestation of #4203. Can you try the workaround suggested there?

"python.terminal.activateEnvironment": false,

(since you're already activating it yourself, having VSCode try to activate it is redundant even if it did work correctly)

[tollvam]

Ok so it removes a part of the error but i have stil

bash-3.2$  env /Users/thomas/opt/anaconda3/bin/python /Users/thomas/.vscode/extensions/ms-python.python-2020.6.88468/pythonFiles/lib/python/debugpy/launcher 52501 -- "/Users/thomas/Desktop/Tom/Prog/Python/Trading Bot/maintenance.py" 
bash: env: No such file or directory
bash-3.2$ 

and as mentioned in the first post, all the folder / files exist

[int19h]

I'm at a loss at this point. The extension itself simply submits a command line that starts with env to the terminal. If bash is complaining that env not found, that's not something that we have any control over.

I also don't understand how it can fail in this case, but work when you manually use env inside the VSCode terminal, since it's the same exact command. Can you confirm that you're using the same terminal (and thus the same shell) that's used for the debugger command line?

[tollvam]

I've recorded a video here, replicating the bug :
https://imgur.com/a/tm2Flj3

[int19h]

Note that it creates a new terminal to run the debugger command line in. This is the one that I'd like to find out more about. If you try to use env in it after debugger does its thing (and fails), does it also fail to find it? If yes, what does $PATH look like?

[tollvam]

Oh ok, env doesn't work and $PATH doesn't return anything

[int19h]

I think this might have something to do with microsoft/vscode#70248. Can you try the workarounds suggested there - "terminal.integrated.inheritEnv": false, and if that doesn't help, "terminal.integrated.env.osx": {"PATH": ""}.

[tollvam]

The second one was already there, and putting the first one on false didn't help.
Reading the other issue, i have some memories messing up with the bashrc file but i'm pretty sure i was able to use the debugger after that. Thanks for trying to help btw !

[tollvam]

I did

export PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"

in the Python Debug Console and now it works !

[int19h]

Thank you for confirming the root cause!

I just realized that I made a mistake in my earlier suggestion - I meant to suggest trying "terminal.integrated.inheritEnv": true (false is the default on macOS, I think?).

But this might cause other problems as described in the linked issue, so setting PATH directly might still be the way to go. You might be able to use path_helper to just reset it to the default, so that you don't have to repeat all the entries explicitly.

[tollvam]

It was already on 'true' for me but maybe i changed it in the past.
Ok thanks for the tip for the path

[pjckoch]

I encountered the exact same issue and for a while I had to set $PATH every time I started a debugging session as described by @tollvam.

However, now I found that the problem is in fact caused by the "terminal.integrated.env.osx": {"PATH": ""} in my settings.json. Removing that line resolved it.

Since you, @tollvam, mentioned that you also had this line in your settings, I can imagine that this is the solution to your problem as well.