MIEngine can't start after setting PATH

[Smit-tay]

After loading an environment file via envFile (or presumably, also via setting PATH via "environment")
I have experienced this:

sh /tmp/Microsoft-MIEngine-Cmd-41jdiyf6.lf4
env: ‘sh’: No such file or directory

Which prevents the launcher from running the debugger (or doing anything useful)
The problem is that the environment file is intentionally removing normal PATH elements like /usr/bin/, etc... to ensure that the environment that is being executed is pristine.

MIEngine/src/MICore/Transports/RunInTerminalTransport.cs
line 157
cmdArgs.Add("sh");

This I guess must be also a launcher setting
"cmdInterpreter.shellPath" maybe ?

[pieandcakes]

@Smit-tay On my machine, sh is located in /bin. Would prefacing that command with /bin fix the issue you are running into?

[Smit-tay]

Just a quesiton:

Why does the path have to be hard-coded ?
Can it be provided via a variable which the user can set, with a default value of maybe /usr/bin/sh ?
Or, perhaps discovered via "which sh" or something ?

NOTE: This needs to be done before envFile sets up the environment for the debugger

Also, it seems (to me anyway) that the generated MI command script include the hard-coded path to sh on the shebang line.

ex:

#!/bin/sh
echo $$ > /tmp/Microsoft-MIEngine-Pid-ww33cskh.88t ; cd "/home/jack/dev/MY_APP" ; DbgTerm=tty ; set -o monitor ; trap 'rm "/tmp/Microsoft-MIEngine-In-9w3rmr67.mvc" "/tmp/Microsoft-MIEngine-Out-2dhy8shr.kt0" "/tmp/Microsoft-MIEngine-Pid-ww33cskh.88t" "/tmp/Microsoft-MIEngine-Cmd-lke23ca8.l4m"' EXIT ; "/usr/bin/gdb" --interpreter=mi --tty=$DbgTerm < "/tmp/Microsoft-MIEngine-In-9w3rmr67.mvc" > "/tmp/Microsoft-MIEngine-Out-2dhy8shr.kt0" & clear; pid=$! ; echo $pid > "/tmp/Microsoft-MIEngine-Pid-ww33cskh.88t" ; wait $pid;

This is not really the correct way to write a shebang line either
Again, the path to sh should be taken from an option, or determined at program launch - with an allowable option to over-ride the discovered value.

But, if it must be hard-coded, at least use:

#!/usr/bin/env sh

which works almost always

[pieandcakes]

@Smit-tay The problem is that the command we build there is passed to VS Code. It sounds like the bug isn't with the envFile but actually with how VS Code is running that command. The envFile settings is only passed to set up the debuggee and shouldn't affect any of our running of scripts in this scenario.

Can you clarify if not setting envFile works for your scenario?

Why does the path have to be hard-coded ?
Can it be provided via a variable which the user can set, with a default value of maybe /usr/bin/sh ?
Or, perhaps discovered via "which sh" or something ?

We can make it more customizable in the future, but that would take more effort than I can do right now.

[pieandcakes]

@WardenGnaw to investigate providing an option for the shell path.

[Smit-tay]

This is not restricted to envFile using environment will cause the same problem - if PATH is modified to eliminate the path to sh

e.g.

"environment" : [{"name":"PATH","value":"NOT_THE_PATH_/usr/bin/sh"}],

Now, this might seem like a stupid thing to do, but, actually, it's not that uncommon.
PATH might be set intentionally to only the binaries I am working on.

[pieandcakes]

"environment" : [{"name":"PATH","value":"NOT_THE_PATH_/usr/bin/sh"}],

Changing this should not affect it, as those values are used to set the environment for the debuggee, and not the debugger. These calls to sh are used to set up the debugger.

The key/value pairs you add in the environment block in launch.json are then added to our launching gdb commands here and they are executed through gdb's MI interface.

I think what you are running into is a modified path on your machine that you used to launch VS Code itself. To worka round it, we can make the change to !#/usr/bin/env sh in the script (as you suggested) and to specify the full path of /bin/sh to the command calling the script.

[pieandcakes]

Nevermind, I think you are right and theres actually a bug where we are passing the environment variables also to the RunInTerminalCommand which we shouldn't be.

MIEngine/src/OpenDebugAD7/AD7DebugSession.cs

Line 565 in 2a2d619

Env = env

[Smit-tay]

So, how do I get this - I am only running Linux - according to the readme this can only be built under Windows

[pieandcakes]

You would need to wait for an update to the extension. @WardenGnaw Can you update this thread with when an update will happen?

[WardenGnaw]

Yep. We have a pending -insiders4 atm. Once that is published, I'll update MIEngine for the C/C++ extension for the next release.

[sean-mcmanus]

This should be fixed now with 0.27.0-insiders5: https://github.com/microsoft/vscode-cpptools/releases/tag/0.27.0-insiders5

[Smit-tay]

Well, I am still experiencing a problem.

I am running the insiders version:
Version 0.27.0-insiders5: March 26, 2019

Attempting to use envFile
"envFile": "${workspaceFolder}/build/environment_run_linux.env",

Contents of "${workspaceFolder}/build/environment_run_linux.env"
LD_LIBRARY_PATH=THIS_IS_A_TEST:THIS_IS_A_TEST

Launch the debugger with this setting also:
"internalConsoleOptions": "openOnSessionStart",

WIthin the DebugConsole window:

Execute debugger commands using "-exec ", for example "-exec info registers" will list registers in use (when GDB is the debugger)
-exec show env
SHELL=/bin/bash
IMSETTINGS_INTEGRATE_DESKTOP=yes
SESSION_MANAGER=local/unix:@/tmp/.ICE-unix/1494,unix/unix:/tmp/.ICE-unix/1494
COLORTERM=truecolor
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
HISTCONTROL=ignoredups
TERM_PROGRAM_VERSION=1.43.2
GNOME_DESKTOP_SESSION_ID=this-is-deprecated
HOSTNAME=lappy.fritz.box
HISTSIZE=1000
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
CINNAMON_VERSION=4.4.8
XMODIFIERS=@im=none
DESKTOP_SESSION=cinnamon
SSH_AGENT_PID=1699
NO_AT_BRIDGE=1
GREP_COLORS=sl=49;39:cx=49;39:mt=48;5;236;91;1:fn=40;92:ln=49;93:bn=49;92:se=49;39
XDG_SEAT=seat0
PWD=/home/jack/dev/build/
LOGNAME=jack
XDG_SESSION_DESKTOP=cinnamon
XDG_SESSION_TYPE=x11
XAUTHORITY=/run/lightdm/jack/xauthority
XDG_GREETER_DATA_DIR=/var/lib/lightdm-data/jack
GJS_DEBUG_TOPICS=JS ERROR;JS LOG
GDM_LANG=en_US.UTF-8
HOME=/home/jack
LANG=en_US.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=X-Cinnamon
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
IMSETTINGS_MODULE=none
CHROME_DESKTOP=code-url-handler.desktop
GJS_DEBUG_OUTPUT=stderr
XDG_SESSION_CLASS=user
TERM=xterm-256color
GTK_OVERLAY_SCROLLING=0
LESSOPEN=||/usr/bin/lesspipe.sh %s
USER=jack
DISPLAY=:0
SHLVL=1
QT_IM_MODULE=xim
XDG_VTNR=1
XDG_SESSION_ID=2
XDG_RUNTIME_DIR=/run/user/1000
PATH=/home/jack/.local/bin:/home/jack/bin:/home/jack/.local/bin:/home/jack/bin:/home/jack/.local/bin:/home/jack/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/jack/my_bin_utils:/home/jack/my_bin_utils:/home/jack/my_bin_utils
GDMSESSION=cinnamon
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
MAIL=/var/spool/mail/jack
GIO_LAUNCHED_DESKTOP_FILE_PID=2153
GIO_LAUNCHED_DESKTOP_FILE=/usr/share/applications/code.desktop
OLDPWD=/home/jack/dev/
TERM_PROGRAM=vscode
_=/usr/bin/gdb
LINES=11
COLUMNS=109

No indication of LD_LIBRARY_PATH being passed to gdb.

[Smit-tay]

If I set LD_LIBRARY_PATH via
"environment": [{"name":"LD_LIBRARY_PATH",
"value": "THIS_IS_A_TEST:THIS_IS_A_TEST"}]

Then it is propogated to gdb correclty.

[Smit-tay]

Looking at MIDebugEngine/Engine.Impl/DebuggedProcess.cs#L856

It's pretty clear this is abug "of ommission" - in that the environment is only being taken from the "environment" setting, and not also from "envFile"

It's important when this is fixed that those two settings are both processed. IOW, I may choose to use both envFile and environment to create a complete list of environment variables required for my debugee.

In that case it's not entirely clear which should have precendence. I think the default should be to stomp envFIle with environment. IOW if envFile sets PATH=/a/path:/b/path, then environment sets PATH=/c/path, the end result is PATH=/c/path.

Normally this is is handled gracefuly with syntax like: PATH="${PATH}:/c/path"

In which case "environment" would be amending "envFIle" and the result would be PATH=/a/path:/b/path:/c/path

[pieandcakes]

@WardenGnaw Please investigate this issue as a VSCode extension issue.

[pieandcakes]

The envFile is parsed by the extension and not by MIEngine. If there is an issue with it, then the bug is within the extension.

Relevant code is in Extension/src/Debugger/ParsedEnvironmentFile.ts.

[WardenGnaw]

Closing. Continuing investigation via C/C++ extension issue