Cannot debug C++ program in Visual Studio Code installed within WSL

[liuzhiyuan1225]

Tested on WSL in Windows 10 1803 and 1809 with Ubuntu 16.04 and Ubuntu 18.04 installed from Microsoft Store.

Installed Ubuntu desktop using:

sudo apt install ubuntu-desktop
sudo apt install compizconfig-settings-manager

Use VcXsr and MobaXterm for displaying GUI for applications.

VS Code GUI starts correctly, I have installed Microsoft's plugin for C++ development and have correctly set my configure files to debug C++ program (gdb is working correctly in bash in WSL).

When I click "Debug" button, VS Code cannot hit the break-point nor will the program (to be debugged) start. VS Code UI gives no error message but keeps waiting endlessly for debugging to start. Same configuration is working correctly in a native Ubuntu VM.

When I start VS Code using "code --verbose", I have noticed the following messages:

[6776:1121/190140.924349:ERROR:bus.cc(395)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")

Have no idea whether this debug problem have something to do with the above error.

Interestingly, VS Code running in WSL can debug Python programs without a problem.

[therealkenc]

Sad face... I was able to reproduce this on 18282 with VSCode 1.29.1 and vscode-cpptools 0.20.1.

Ref vscode-cpptools/1408 which has similar symptoms which turns out unrelated. Here we fail to launch (nevermind debug), and that other issue was addressed almost a year ago and shouldn't manifest on 1809 (aka 17763) or 18282.

I'll look more when I get a chance (big ask, no promises).

[ed] Circular-ref vscode-cpptools#2870 which is probably where most the action will happen until I get a handle on what changed.

[therealkenc]

The fine details of the cause of the debuggee failing to launch aren't known just yet, but cutting to the chase it isn't a WSL bug. WSL is just doing what it is told, and there is no actionable.

Work-around for now is to use an earlier version of vscode-cpptools, which isn't trivial because VSCode insists on auto-updating by default. You want your launch.json to look like this; specifically "externalConsole": true. All of the dbus bits below are to make gnome-terminal happy.

I'll hold this tracker open for a while until we can say what version of VSCode and/or vscode-cpptools it gets addressed. Ref vscode-cpptools#2842. Folks are seeing a variation of this on Real Linux™ as well.

$ sudo apt purge code
$ rm -fr ~/.vscode ~/.config/Code*
$ wget  -O code-1.29.1-stable.deb https://vscode-update.azurewebsites.net/1.29.1/linux-deb-x64/stable
$ sudo dpkg -i code-1.29.1-stable.deb
$ mkdir -p ~/.config/Code/User
$ echo '{ "extensions.autoUpdate": false }' > ~/.config/Code/User/settings.json
$ wget -O cpptools-0.18.1-linux.vsix https://github.com/Microsoft/vscode-cpptools/releases/download/v0.18.1/cpptools-linux.vsix
$ code --install-extension cpptools-0.18.1-linux.vsix
$ sudo apt install gnome-terminal
$ export NO_AT_BRIDGE=1
$ sudo service dbus start
$ exec dbus-run-session -- bash
$ mkdir hello && cd hello
$ wget -O hello.c https://goo.gl/uFLgoJ
$ gcc -g hello.c
$ /usr/bin/code -n .

[therealkenc]

I'll hold this tracker open for a while until we can say what version of VSCode and/or vscode-cpptools it gets addressed

Nah. Two weeks since OP is long enough, and this one will just go chirping crickets since no WSL actionable. If I find further work-around on typical Ubuntu-on-WSL installs I'll post a follow up, but there is no WSL system actionable (for now anyway) so closing. This is tag linux-behavior or external depending on how you look at it. Going with the latter arbitrarily.

[therealkenc]

The issue causing vscode-cpptools to fail to launch appears to be addressed with a combination of vscode-cpptools 0.21.0 and VSCode 1.30.2.

Note that the debugger can still fail to launch if you have chosen "externalConsole": true in your launch.json, and you don't have your default console (typically gnome-terminal) set up correctly. If you don't mind (or prefer) the internal console ("externalConsole": false) then don't worry about it. The internal console works fine now with the above version combination. When in doubt, pick the internal console.

If you want the external console, you'll need the steps posted earlier:

$ sudo apt install gnome-terminal
$ export NO_AT_BRIDGE=1
$ sudo service dbus start
$ exec dbus-run-session -- bash
$ /usr/bin/code -n .

That is, VS Code needs to be started in a dbus session, otherwise when VS Code tries to launch the gnome-terminal external console it will fail, and you'll get the nonobvious behavior of the debugger failing to start.

[ed] There are also some configuration knobs you can tweak if you'd prefer a different external terminal console. The magic ~/.config/Code/User/settings.json entries are:

    "terminal.explorerKind": "external",
    "terminal.external.linuxExec": "x-terminal-emulator"

If you'd prefer to avoid the dbus heartache, change x-terminal-emulator to something less needy like xterm (ensuring xterm is installed, natch).

That's about a wrap on this one. Hopefully the VS Code folks can improve the diagnostics a little, but failing to have a dbus session or functioning gnome-terminal (or other console) isn't strictly speaking their problem.