vscode-fhs run from nix develop cannot launch terminal or extensions with binaries

[kjeremy]

Describe the bug

vscode-fhs fails to launch the terminal process (and other extension issues) if launched from within a nix develop session.

Steps To Reproduce

Steps to reproduce the behavior:

1. Add vscode-fhs to your configuration.nix
2. Run git clone https://github.com/breakds/flake-example-hello-repeater
3. Run nix develop
4. Run code .
5. Go to the Terminal Menu and select New Terminal

Expected behavior

A Terminal window should pop up. Instead the bash process dies.

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

This also impacts cmake from the CMake Tools extension. The same problem manifests in the Nix Env Selector extension as missing symbols from nix-shell.

Notify maintainers

@eadwu @Synthetica9 @maxeaubrey @bobby285271

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
these 4 paths will be fetched (0.03 MiB download, 0.15 MiB unpacked):
  /nix/store/4ybkncn05qbhgbdxg9sxdgpm1jpdx76w-gcc-wrapper-10.3.0
  /nix/store/83l8wwrx7xs3mh9sbbj6whmyx8y4cz36-stdenv-linux
  /nix/store/c4k3fcsp5cqg9v0rpac9qbqmbkm6a7pk-binutils-wrapper-2.35.2
  /nix/store/wsjfqi1r5f6r9jvxm8kji8q0cdahfjpl-expand-response-params
copying path '/nix/store/wsjfqi1r5f6r9jvxm8kji8q0cdahfjpl-expand-response-params' from 'https://cache.nixos.org'...
copying path '/nix/store/c4k3fcsp5cqg9v0rpac9qbqmbkm6a7pk-binutils-wrapper-2.35.2' from 'https://cache.nixos.org'...
copying path '/nix/store/4ybkncn05qbhgbdxg9sxdgpm1jpdx76w-gcc-wrapper-10.3.0' from 'https://cache.nixos.org'...
copying path '/nix/store/83l8wwrx7xs3mh9sbbj6whmyx8y4cz36-stdenv-linux' from 'https://cache.nixos.org'...
 - system: `"x86_64-linux"`
 - host os: `Linux 5.15.34, NixOS, 22.05 (Quokka), 22.05.20220417.1ffba9f`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.8.0pre20220411_f7276bc`
 - channels(root): `"nixos"`
 - channels(jkolb): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[nashamri]

I have the same issue

 - system: `"x86_64-linux"`
 - host os: `Linux 5.17.3, NixOS, 22.05 (Quokka)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.7.0`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[d4hines]

I noticed this issue upgrading nixpkgs from rev 1d08ea2bd83abef174fb43cbfb8a856b8ef2ce26 to rev 30d3d79b7d3607d56546dd2a6b49e156ba0ec634

I was getting a libc error undefined symbol: __nptl_change_stack_perm.

[aameen-tulip]

I started having the exact same issue with code depending on libX11.so.6. Initially I'll get GLIBC_2.34 no found (required by ...-libX11-1.7.2/lib/libX11.so.6. Then if I add pkgs.glibc to the environment ( v2.34 ), I get a crash during resolution exactly like yours: undefined symbol: __nptl_change_stack_perm. From what I could tell in the glibc sources this is a system call, I only saw it mentioned in glibc 2.35, but I didn't dig to find out if it was "new in 2.35"; if that's the case symbol versioning in glibc itself really dropped the ball.

Still, I'm not sure how libX11.so.6 would depend on glibc-2.35 since it's not available in nixpkgs, and literally everything on my box was installed using nix.

[kjeremy]

I'm wondering if we need to be explicit about glibc versions somewhere. I'm not sure how to solve this and it makes vscode unusable.

[kjeremy]

I'm pretty sure that this is a libc mismatch.

ldd --version on my system reports: 2.34

Once in the nix develop it reports 2.32

[kjeremy]

Have any of you figured out a workaround?

[kjeremy]

We now see this on 21.11

- system: `"x86_64-linux"`
- host os: `Linux 5.10.81, NixOS, 21.11 (Porcupine)`
- multi-user?: `yes`
- sandbox: `yes`
- version: `nix-env (Nix) 2.5.0pre20211206_d1aaa7e`
- channels(root): `"nixos-21.11.337635.cbd40c72b26"`
- nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[wcole3]

I can add that if instead of specifying vscode-fhs in the environment system packages you specify vscode-with-extensions.override with the extensions explicitly listed, the terminal launches in vscode. I'm also able to run nix commands inside of the integrated terminal of other projects that were failing due to glibc errors previously so I'd say its a step in the right direction, though managing extensions like this is not the most pleasant.

Not entirely familiar with Nix so if you know of gotchas with this method please let me know. Obviously, this doesn't address the root issue (since many other related issues exist), but it at least seems to allow vscode to play nicer with Nix.

[ParetoOptimalDev]

I'm unable to reproduce this and the terminal works fine with a recent nixpkgs unstable pin:

• system: "x86_64-linux"
• host os: Linux 5.15.59, NixOS, 22.11 (Raccoon), 22.11.20220814.b02538b
• nixpkgs rev: 5efc8ca954272c4376ac929f4c5ffefcc20551d5

[Adam-D-Lewis]

In case this is helpful, I only see this issue when most of my packages are from one branch (e.g. 22.05) and my vscode-fhs is from unstable. When using vscode-fhs from 22.05 also, I don't see this issue.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/vscode-c-cpptools-and-clangd-not-working/21902/6

[DarthPJB]

In case this is helpful, I only see this issue when most of my packages are from one branch (e.g. 22.05) and my vscode-fhs is from unstable. When using vscode-fhs from 22.05 also, I don't see this issue.

I can very much confirm this is the case - I switched my project flake to use unstable and the default vscode.fhs environment worked correctly.

I'm going to thus suppose that vscode.fhs (running from my nixos-unstable system) is linked against a different glibc, or potentially built with a different gcc.

I personally can't think of any potential fix besides running vscode.fhs from the project-shell to get a matching version.

[MathiasSven]

Is there potentially a roundabout way to fix this in which the binary is wrapped with its own libraries to avoid this issue? I have run many binaries inside of vscode-fhs but only recently did I see one that didn't work. This of course at the cost of having multiple versions of the same library taking up space on the nix store