Running VS Code native in WSL

[mredbishop]

I'm aware this is not supported yet but obviously a lot of work has been done around it so I thought I'd raise this as it's SOOOO close now! With dbus and various other issues out of the way, the only remaining fatal issue seems to be the check failed issue shown below. I've also raised this in the VS Code github as I am not sure which team it relates to?

• VSCode Version: 1-14-0.insider
• OS Version: Windows 10 with creators update. (I'll try again with the preview build this evening)

Steps to Reproduce:

1. Install VcXsrv and configure to use single screen using XLaunch.
2. Open "Bash on Ubuntu on Windows"
3. execute LIBGL_ALWAYS_INDIRECT=1 DISPLAY=:0 code-insiders --verbose

Reproduces without extensions: Yes

Stack:

[4533:0706/153512.810904:WARNING:audio_manager.cc(317)] Multiple instances of AudioManager detected
[4533:0706/153512.810991:WARNING:audio_manager.cc(278)] Multiple instances of AudioManager detected
[4533:0706/153512.815020:FATAL:udev_linux.cc(20)] Check failed: monitor_.
#0 0x000001af7a0e <unknown>
#1 0x000001adccab <unknown>
#2 0x00000277b426 <unknown>
#3 0x000001a4118b <unknown>
#4 0x000001ae010e <unknown>
#5 0x000001b332ac <unknown>
#6 0x000001b33558 <unknown>
#7 0x000001b338bb <unknown>
#8 0x000001ae2469 <unknown>
#9 0x000001b33047 <unknown>
#10 0x000001b15460 <unknown>
#11 0x000002561126 <unknown>
#12 0x0000025612d9 <unknown>
#13 0x000001b4b165 <unknown>
#14 0x000001b25693 <unknown>
#15 0x7f36524576ba start_thread
#16 0x7f364b9673dd clone

[therealkenc]

#1233. Curious. "So close" is exactly what MaximoTrinidad said (message). You can cure your Check failed: monitor_ problem over here. That's #1121 if you are keeping track.

[mredbishop]

I have got past this error now and have no more hard errors showing in the verbose output but it still doesn't show in the X Interface, I don't know why as most other apps I try do.

I should point out that to get past the UDEV monitor issue I followed instructions to install libudev-stub at https://github.com/therealkenc/libudev-stub

[corford]

Just wanted to say I'm at exactly the same point and can't get past it. Steps to reproduce (from a clean WSL Ubuntu install):

C:\bash.exe
# sudo apt-get remove openssh-server
# sudo apt-get install openssh-server
# nano /etc/ssh/sshd_config [ ListenAddress 0.0.0.0; UsePrivilegeSeparation no; PermitRootLogin no; UseDNS no; X11Forwarding yes; X11DisplayOffset 10; AllowUsers <username> ]
# sudo service ssh --full-restart
# sudo apt-get install libgtk2.0-0 libxss-dev libasound2 mesa-utils
# curl https://github.com/therealkenc/libudev-stub/releases/download/v0.9.0/libudev-stub-0.9.0-WSL.deb > libudev-stub-0.9.0-WSL.deb
# sudo dpkg -i libudev-stub-0.9.0-WSL.deb
# curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.gpg
# sudo mv microsoft.gpg /etc/apt/trusted.gpg.d/microsoft.gpg
# sudo sh -c 'echo "deb [arch=amd64] https://packages.microsoft.com/repos/vscode stable main" > /etc/apt/sources.list.d/vscode.list'
# sudo apt-get update
# sudo apt-get install code-insiders
# code-insiders --verbose

Yields:

[3836:0829/204549.906338:ERROR:bus.cc(427)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
[3836:0829/204550.001483:WARNING:audio_manager.cc(295)] Multiple instances of AudioManager detected
[3836:0829/204550.001547:WARNING:audio_manager.cc(254)] Multiple instances of AudioManager detected
UDEV STUB: Using libudev-stub 0.9.0
UDEV STUB: udev_new()
UDEV STUB: stubbing udev...
UDEV STUB: udev_monitor_new_from_netlink() name: udev
UDEV STUB: udev_monitor_filter_add_match_subsystem_devtype() subsystem: sound devtype: (null)
UDEV STUB: udev_monitor_filter_add_match_subsystem_devtype() subsystem: video4linux devtype: (null)
UDEV STUB: udev_monitor_enable_receiving()
UDEV STUB: udev_monitor_get_fd()
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast

Trying with the --disable-gpu flag gets rid of the libGL error but nothing more.

This is with version: 1.16.0-insider d0d00e882437092f521d2d7893cc56ee296d278f

[sunilmut]

@corford - Try sudo /etc/init.d/dbus start first.

[corford]

@sunilmut Thanks! Sadly, still gets stuck in the same place (but dbus message is now gone 👍 )

# sudo /etc/init.d/dbus start
 * Starting system message bus dbus                                      [ OK ]
# code-insiders --verbose

[4875:0829/222548.534763:WARNING:audio_manager.cc(295)] Multiple instances of AudioManager detected
[4875:0829/222548.534935:WARNING:audio_manager.cc(254)] Multiple instances of AudioManager detected
UDEV STUB: Using libudev-stub 0.9.0
UDEV STUB: udev_new()
UDEV STUB: stubbing udev...
UDEV STUB: udev_monitor_new_from_netlink() name: udev
UDEV STUB: udev_monitor_filter_add_match_subsystem_devtype() subsystem: sound devtype: (null)
UDEV STUB: udev_monitor_filter_add_match_subsystem_devtype() subsystem: video4linux devtype: (null)
UDEV STUB: udev_monitor_enable_receiving()
UDEV STUB: udev_monitor_get_fd()
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast

[therealkenc]

This issue remains an abject dupe of #1233. The udev stub is obsolete as of 16275, FWIW. Which changes nothing regarding VSCode, because VSCode does not work for reasons unrelated to udev (or dbus).

[corford]

Yep, apologies for resurrecting it. Looks like VSCode under WSL is still a way off (if it happens at all).

[therealkenc]

Looks like VSCode under WSL is still a way off

Maybe. Maybe not. The reason VSCode does not light up is because the IPC message to fire the method that launches the window never makes it, or never gets sent in the first place. That could be for lots of reasons. Sunil might find and fix the problem next week, given a tight repro. Maybe it's a one liner bug. Or it might take another nine months, based on the fact that the same issue has existed for the last nine months. Absent a tight repro, getting the libuv test suite to pass (#1744 May 1 message) is a good place to start. See also honourable mention in #1910. #2333 would go a long way too, and is being looked at.

[inter1965]

Did somebody try to get xpra under wsl to work? This might be another alternative.

[therealkenc]

Did somebody try to get xpra under wsl to work? This might be another alternative.

The vscode blocker(s) is(are) not display related.

[dbaeumer]

I digged a little bit into this and I found the reason why VS Code is not starting up. It is as follows: for some reason which I don't know the async callbacks passed to Node API calls aren't invoked. Since VS Code main code and loader heavily depends on async file reads and other async Node API the main process is pretty early waiting for callbacks which never fire.

This can easily be reproduced / demoed using the electron starter app:

• clone https://github.com/electron/electron-quick-start.git inside WSL
• cd electron-quick-start
• npm install
• open main.js
• add the following to the top of the createWindow function

  console.log('In createWindow')
  setInterval(function() {
    console.log('Event loop is running')
  }, 1000)

• do all the xserver settings
• npm start

Observe: the electron app starts but no Event loop is running is printed to the terminal. Interestingly it is printed once when the electron app is closed.

This is not a general problem of the electron / node under WSL. If you run electron as pure node everything works. To check do the following:

• create new electronNode.js

  console.log('In main');
  setInterval(function() {
    console.log('Event loop is running');
  }, 1000);

• in a terminal do export ELECTRON_RUN_AS_NODE=1
• execute ./node_modules/electron/dist/electron electronNode.js from the electron-quick-start directory

I have to say that I am not a WSL or C / Chromium / Node / Electron expert so I have no idea of why the event loop is not running (so I guess some native event is missing to make it go :-)). If someone fixes this I am happy to continue getting VS Code up on WSL.

[rvaneijk]

Even though the team that works on VSCode may be small, promoting VSCode to run on various platforms EXCEPT window's own WSL seems a bit strange to me. One of the reasons for WSL is to attract developers to a Windows base system. The two teams, i.e., VSCode and WSL, should drink some coffee to fix this issue. Being able to run VSCode within WSL would make many happy.

[therealkenc]

run on various platforms EXCEPT window's own WSL seems a bit strange to me

That was brought up here. 31 unanimous down-votes as of this writing. If it seems "strange" to you, please re-read the WSL FAQ and the post above yours. Fun fact: Electron is not a MSFT product. It is maintained by GitHub (and others), and is based on code from Google (and others). GitHub and Google could in theory expend development resources to find out why their stuff doesn't work on WSL. But then they probably read Microsoft's WSL FAQ and decided they had plenty of their own Electron and Chromium bugs to fix instead.

I started taking another run at it (now that #2333 is squashed), but the recipe I have been using to build electron from source is failing with 1.7.9 for some reason unrelated to WSL. I hadn't considered that drinking coffee might fix the issue, so I'm out to Starbucks now.

[therealkenc]

Okay so I've confirmed the suspicion I've alluded to previously. The problem relates to an epoll_wait() call, either directly or (possibly) as secondary fail due a more obscure primary cause.

For background, the reason Dirk's electronNode.js test case works (and indeed most of node proper or people's heads would explode) and his main.js createWindow() case does not, is because in the latter electron has to inject itself into the event loop using eventfd IPC. The event loop is running alright, but the IPC is stuck.

Why, precisely, it is stuck I can't tell you right now. But anyway "there's your problem". The relevant code in the backtrace is NodeBindingsLinux::PollEvents(). The reason Dirk is getting one "Event loop is running" output line when the app is closed is because exiting unblocks the call, once, in its last dying gasp.

I did the test with electron off master (which is v1.8.2-beta.2-ish) because I never did get 1.7.9 compiling. But it doesn't matter for our purposes because the basic structure has remained the same since the beginning of time.

The test case I am using is stripped down a little further than Dirk's. It does not actually launch a GTK window, and thus avoids a lot of superfluous syscall verbosity loading an html page and painting. CLI use case. Or something.

// main.js
const electron = require('electron')
const app = electron.app

function doStuff() {
  console.log('In doStuff')
  setImmediate(function() {
    console.log('Whee!');
    process.exit();
  })
}

app.on('ready', doStuff)

On Real Linux™ it will spit out In doStuff + Whee! and exit cleanly. On WSL it prints In doStuff and hangs.

Real Linux strace output here and WSL strace output here. But I mostly recommend against bothering because there are no hard fails (EINVAL, ENOSYS, etc). The two diverge badly enough that I can't pinpoint a conclusive gotcha. gdb shows "thread 24" blocking on epoll_wait(). This is on 17046.

[... args are --disable-gpu .]
(gdb) info threads
  Id   Target Id         Frame 
* 1    Thread 0x7fffdf1d0a80 (LWP 8579) "electron" 0x00007fffe4e9b70d in poll () at ../sysdeps/unix/syscall-template.S:84
  2    Thread 0x7fffde380700 (LWP 8583) "sandbox_ipc_thr" 0x00007fffe4e9b70d in poll () at ../sysdeps/unix/syscall-template.S:84
  3    Thread 0x7fffdc870700 (LWP 8585) "WorkerPool/8585" pthread_cond_timedwait@@GLIBC_2.3.2 ()
    at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
[.... blah blah blah many threads doing various things]
  24   Thread 0x7fff7bff0700 (LWP 8608) "electron" 0x00007fffe4ea79d3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84
(gdb) thread 24
[Switching to thread 24 (Thread 0x7fff7bff0700 (LWP 8608))]
#0  0x00007fffe4ea79d3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84
84	../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0  0x00007fffe4ea79d3 in epoll_wait () at ../sysdeps/unix/syscall-template.S:84
#1  0x0000000000d51b6e in atom::NodeBindingsLinux::PollEvents (this=0x2180660) at ../../atom/common/node_bindings_linux.cc:48
#2  0x0000000000d4e6d6 in atom::NodeBindings::EmbedThreadRunner (arg=0x2180660) at ../../atom/common/node_bindings.cc:289
#3  0x00007fffeb5676ba in start_thread (arg=0x7fff7bff0700) at pthread_create.c:333
#4  0x00007fffe4ea73dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb) 

[therealkenc]

Consolidated repro notes for anyone one who feels inclined to play along and does not want to scour the Interwebs.

wsl-electron-build-notes.txt

[sgharms]

So my understanding of this issue is that if it were fixed, we would have a universe where we:

• compile vscode in WSL
• run VScode in WSL
• (Nota Bene) renders via X

No doubt, that's a huge leap forward and establishes ever closer parity from WSL to Real Linux(tm) –
definitely a 🎉 moment.

But I think that might be more ambitious than what this issue actually needs, and I'll beg for @mredbishop 's understanding if this is a hijack of his needs. I think what he, and I, and others really want is:

The Holy Grail

• compile vscode in WSL
• execute vscode(or some wrapper script) from WSL to the equivalent experience of running a downloaded vscode. I dream of WSL builds being on par with what I might have made under PowerShell.

As far as I can tell, X is just a hack to get something from WSL land on the screen. Who wants that when The Holy Grail is prettier (although may occasion more work!)

Question: Is it conceivable that my holy grail scenario would ever be possible and how hard is it? While the FAQ readily sets the expectation that building and running GUI apps from WSL into Windows via X might not be possible, My interpretation of the FAQ suggests that 1) running a C- and Node-based build process to create a binary executable and 2) executing Windows apps from WSL are reasonable expectations.

Use Case: Here's a use case. I'd like to have the vspython plugin for VS code use WSL-configured Python instances for debugging, etc. I'd like to try to write a patch to make that possible. But as it stands, I would have to download and install the native build toolchain instead of simply using the robust toolchain inside of WSL. I want to contribute to VSCode. I want to add in some debugging output and some print statements so that I can learn to contribute. And then I want to get VSCode to work with my Python setup. The limit is the inability to build, in WSL, a VSCode from source. The addition of an X server is obfuscatory. I don't think VSCode would-be hackers are thrilled to run X – they want to get in a code, debug, repair cycle between WSL and WIP-builds of VSCode.

Addendum: @therealkenc and @dbaeumer have provided amazing debug output. Output that I'm not fit to appreciate or comment on. I'm trying to follow your steps and learn more.

I disagree with the tone of the comment made by another user that @therealkenc linked to. I believe the tone of this individual's comment is what's receiving the thumbs-down, not the dream that it, underneath its mantle of bluster, shares which is, effectively, what I call "The Holy Grail."

I'm hoping that my asking this question in a more calm way isolates and clarifies the true goal of these issues Again, my heartfelt gratitude to what you electron -hackers and C-gurus have already discerned.

[dbaeumer]

When digging into this I was able to compile VS Code from source in WSL using the normal tool chain used to compile VS Code under Linux. However I was not able to run it due to the problems outlined here #2293 (comment)

[therealkenc]

Yeah compiling VS Code (or any other node app) is no problem in WSL. Node, npm, tsc, gulp, and the rest of the build bits have worked on WSL for quite some time. You can even remote debug VS Code (the main.js side) using Windows (or Mac) VS Code, which I did back in November 2016. But VS Code makes about the worse test case ever for finding syscall level bugs.

The most constructive thing that can be done here is to reach out to friendly contacts on the Electron / libuv teams, if you have any. Electron#6722 was opened by someone once, but I have been loath to comment over there (for a year); because, asking them to chase known WSL problems is kind of cruel. Again, the libuv test suite doesn't pass on WSL and that test-poll.c fail is a red flag if I ever saw one.

[mredbishop]

This has got way off track, go look at the latest on this at #2760 Running VSCode for Linux in WSL #2760