vscode-fhs and vscodium-fhs crash on execution for non-NixOS

[ramesh45345]

Describe the bug

Both the vscode-fhs and vscodium-fhs packages crash on execution when run on a non-NixOS operating system. Behavior was observed on Arch Linux (libvirt/qemu VM), Fedora Kinoite 35 (VM, and host with nVidia driver), and Ubuntu 21.10 (VM), all x86_64-linux.

On all machines, home-manager with a stock config (none or one additional packages installed), along with an up-to-date nix (2.7.0). Nix was installed using single user mode.

Both of these packages do execute correctly when tested on NixOS, the problem is only observed when using Nix on a non-NixOS platform.

The following log is observed for vscodium-fhs (which does not show useful information):

$ nix-shell -p vscodium-fhs --command "codium --version"
1.65.2
c722ca6c7eed3d7987c0d5c3df5c45f6b15e77d1
x64
$ nix-shell -p vscodium-fhs --command "codium --verbose --log=trace"
Gtk-Message: 21:03:17.439: Failed to load module "canberra-gtk-module"
Gtk-Message: 21:03:17.470: Failed to load module "colorreload-gtk-module"
Gtk-Message: 21:03:17.471: Failed to load module "window-decorations-gtk-module"

The following log is observed for vscode-fhs (not very interesting either):

$ nix-shell -p vscode-fhs --command "code --version"
1.65.2
c722ca6c7eed3d7987c0d5c3df5c45f6b15e77d1
x64
$ nix-shell -p vscode-fhs --command "code --verbose --log=trace"
Gtk-Message: 21:05:08.773: Failed to load module "canberra-gtk-module"
Gtk-Message: 21:05:08.808: Failed to load module "colorreload-gtk-module"
Gtk-Message: 21:05:08.808: Failed to load module "window-decorations-gtk-module"
[53:0412/210508.849696:ERROR:angle_platform_impl.cc(44)] Display.cpp:840 (initialize): ANGLE Display::initialize error 12289: glXQueryExtensionsString returned NULL
[53:0412/210508.850074:ERROR:gl_surface_egl.cc(780)] EGL Driver message (Critical) eglInitialize: glXQueryExtensionsString returned NULL
[53:0412/210508.850336:ERROR:gl_surface_egl.cc(1373)] eglInitialize OpenGL failed with error EGL_NOT_INITIALIZED, trying next display type
[53:0412/210508.850722:ERROR:angle_platform_impl.cc(44)] Display.cpp:840 (initialize): ANGLE Display::initialize error 12289: glXQueryExtensionsString returned NULL
[53:0412/210508.850904:ERROR:gl_surface_egl.cc(780)] EGL Driver message (Critical) eglInitialize: glXQueryExtensionsString returned NULL
[53:0412/210508.851119:ERROR:gl_surface_egl.cc(1373)] eglInitialize OpenGLES failed with error EGL_NOT_INITIALIZED
[53:0412/210508.851332:ERROR:gl_initializer_linux_x11.cc(178)] GLSurfaceEGL::InitializeOneOff failed.
[53:0412/210508.852404:ERROR:viz_main_impl.cc(160)] Exiting GPU process due to errors during initialization
[64:0412/210508.880678:ERROR:gpu_init.cc(440)] Passthrough is not supported, GL is swiftshader
[main 2022-04-13T01:05:08.965Z] [File Watcher (node.js)] Request to start watching: /home/user/.config/Code/User (excludes: <none>),/home/user/.config/Code/User/settings.json (excludes: <none>)
[main 2022-04-13T01:05:08.982Z] Starting VS Code
[main 2022-04-13T01:05:08.982Z] from: /nix/store/57xhiklf9hvrlk8y0n73xppai2sz2wx3-vscode-1.65.2/lib/vscode/resources/app
[main 2022-04-13T01:05:08.982Z] args: {
  _: [],
  diff: false,
  add: false,
  goto: false,
  'new-window': false,
  'reuse-window': false,
  wait: false,
  help: false,
  'list-extensions': false,
  'show-versions': false,
  'pre-release': false,
  version: false,
  verbose: true,
  log: 'trace',
  status: false,
  'prof-startup': false,
  'no-cached-data': false,
  'prof-v8-extensions': false,
  'disable-extensions': false,
  'disable-gpu': false,
  'ms-enable-electron-run-as-node': false,
  telemetry: false,
  debugRenderer: false,
  logExtensionHostCommunication: false,
  'skip-release-notes': false,
  'skip-welcome': false,
  'disable-telemetry': false,
  'disable-updates': false,
  'disable-keytar': false,
  'disable-workspace-trust': false,
  'disable-crash-reporter': false,
  'skip-add-to-recently-opened': false,
  'unity-launch': false,
  'open-url': false,
  'file-write': false,
  'file-chmod': false,
  'driver-verbose': false,
  force: false,
  'do-not-sync': false,
  trace: false,
  'force-user-env': false,
  'force-disable-user-env': false,
  'open-devtools': false,
  __sandbox: false,
  'no-proxy-server': false,
  'no-sandbox': false,
  nolazy: false,
  'force-renderer-accessibility': false,
  'ignore-certificate-errors': false,
  'allow-insecure-localhost': false,
  'disable-dev-shm-usage': false,
  logsPath: '/home/user/.config/Code/logs/20220412T210508'
}
[main 2022-04-13T01:05:08.984Z] Resolving machine identifier...
[main 2022-04-13T01:05:08.985Z] Resolved machine identifier: 743a96d627a885f58f870320cc80e748ca8792b94b37a67bbdb69e2ac8b42295
[main 2022-04-13T01:05:08.986Z] Main->SharedProcess#connect
[main 2022-04-13T01:05:08.996Z] [File Watcher (node.js)] Started watching: '/home/user/.config/Code/User'
[main 2022-04-13T01:05:08.997Z] [File Watcher (node.js)] Error: ENOENT: no such file or directory, stat '/home/user/.config/Code/User/settings.json'
[main 2022-04-13T01:05:09.014Z] StorageMainService: creating global storage
[main 2022-04-13T01:05:09.034Z] lifecycle (main): phase changed (value: 2)
[main 2022-04-13T01:05:09.036Z] windowsManager#open
[main 2022-04-13T01:05:09.037Z] windowsManager#open pathsToOpen [ [Object: null prototype] {} ]
[main 2022-04-13T01:05:09.038Z] windowsManager#doOpenEmpty {
  restore: false,
  remoteAuthority: undefined,
  filesToOpen: undefined,
  forceNewWindow: false
}
[main 2022-04-13T01:05:09.039Z] IPC Object URL: Registered new channel vscode:625266b3-2e5d-4226-b320-ffa1435aec28.
[main 2022-04-13T01:05:09.040Z] window#validateWindowState: validating window state on 1 display(s) {
  width: 1024,
  height: 768,
  mode: 1,
  x: 128,
  y: 260,
  hasDefaultState: true
}
[main 2022-04-13T01:05:09.040Z] window#validateWindowState: 1 monitor working area { x: 0, y: 28, width: 1280, height: 1235 }
[main 2022-04-13T01:05:09.040Z] window#ctor: using window state {
  width: 1024,
  height: 768,
  mode: 1,
  x: 128,
  y: 260,
  hasDefaultState: true
}

Steps To Reproduce

1. Ensure that vscode and vscodium configuration (in .config, and root of home folder) have been removed to ensure a clean run.
2. On a non-NixOS operating system, with Nix installed in single user mode, run nix-shell -p vscodium-fhs --command "codium --verbose --log=trace"
3. Observe that the program does not run. Note that there is no trace in the console when executing.
4. On a non-NixOS operating system, with Nix installed in single user mode, run nix-shell -p vscodium --command "codium --verbose --log=trace"
5. Observe that the program executes and loads the editor.

Expected behavior

It is expected that the program loads successfully.

Additional context

As stated above, vscode-fhs and vscodium-fhs work properly on NixOS, but not on other Linux OSes.

Is it normal for fhs packages to not work in non-NixOS? Is it possible I have a configuration issue?

Notify maintainers

@Synthetica9 @turion @bobby285271 @eadwu @maxeaubrey

Metadata

$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.17.1-arch1-1, Arch Linux, noversion, rolling`
 - multi-user?: `no`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.7.0`
 - channels(user): `"home-manager, nixpkgs"`
 - nixpkgs: `/home/user/.nix-defexpr/channels/nixpkgs`

[turion]

Wow. Thanks for the detailed report. It's quite telling that we have vscodium-fhs since some time now already, and haven't been aware of the bug. nixpkgs development seems NixOS-biased, as all the integration tests are NixOS AFAIK. Maybe we should have some integration tests with other OSes as well.

In this case, for nearly all non-NixOS Linux distros, one should use vscodium instead of vscodium-fhs, since the sole purpose of vscodium-fhs is to mimick the existence of the Linux File Hierarchy Standard, which is given in most other distros. So I'm not quite sure whether this issue is going to be resolved any time soon.

[ramesh45345]

@turion Thank you for your quick response!

Understood that this is probably not a common use case. Just to give some background of why I might want to do this, I run another immutable OS on most of my systems (Fedora Silverblue/Kinoite), so using Nix to install apps tends to be one easy avenue to not pollute the host OS. Since vscode tends to need lots of dev sdks (i.e. python, ruby, dotnet, etc), it is helpful to install them with vscode/codium to use them natively. As for why I didn't just use vscodium, rarer extensions may not be in the nixpkgs archive, and it may not be worth a maintainers time to add and maintain the rare extensions over time. Also, I could use Flatpak, but using SDKs with those editions of vscode/codium is somewhat rough (i.e. installing pip modules inside the flatpak would disappear over time). There are also other edge cases that make Flatpak less appealing (i.e. issues with system integration, git push/pull, etc).

[berbiche]

glXQueryExtensionsString returned NULL

This is most likely related to the opengl driver problem Nix packages have when running on non-NixOS systems.

See #9415.

@ramesh45345 can you try running codium with the flag --disable-gpu?

[ramesh45345]

@berbiche Thanks for the tip. I admit I had wondered if GL drivers were a culprit when I experienced this issue on a machine with the nvidia driver. Unfortunately the --disable-gpu flag doesn't seem to change much. Here is the output for vscodium-fhs.

$ nix-shell -p vscodium-fhs --command "codium --verbose --log trace --disable-gpu --version"
1.65.2
c722ca6c7eed3d7987c0d5c3df5c45f6b15e77d1
x64
$ nix-shell -p vscodium-fhs --command "codium --verbose --log trace --disable-gpu"
Gtk-Message: 15:26:03.745: Failed to load module "colorreload-gtk-module"

Same sort of output, no real change (program doesn't load). I also tried using nixGL (a non-NixOS wrapper for GL drivers) in a previous attempt, to no avail. I may later on try some of the workarounds mentioned in the linked report, but I'm unsure if this actually is a GL issue, or some other issue, since I get GL errors with normal code and codium, and those will still launch inside a VM environment.