VS Code and other processes dump core unexpectedly

I’m on NixOS 23.05 and quite new to Nix overall. After recent updates via nixos-rebuild switch --upgrade, I’ve started experiencing violent process crashes. VS Code won’t start at all, neither from the command line nor from a desktop shortcut. journalctl -xe reveals that VS Code dumps core when starting up.

Here’s the log entry.

The following is an excerpt from users.users.viluon.packages in /etc/nixos/configuration.nix that defines my VS Code installation:

(vscode-with-extensions.override {
        vscodeExtensions = with vscode-extensions; [
        ] ++ pkgs.vscode-utils.extensionsFromVscodeMarketplace [
            name = "craftos-pc";
            publisher = "jackmacwindows";
            version = "1.2.2";
            sha256 = "sha256-A+MNroXv0t9Mw/gr0Fyov3cXyF/GGzwRLKrIxQ2tKCE=";
            name = "copilot-chat";
            publisher = "GitHub";
            version = "0.9.2023100901";
            sha256 = "sha256-EFMmUQnX+cizuzZCAo0t40l2b9/sY3Rrlm0BeLbfqiM=";
            name = "copilot-labs";
            publisher = "GitHub";
            version = "0.15.1019";
            sha256 = "sha256-XQU3+XG6zJjpu43reE1MKhnHhR5s90wk7T9yIxj0s4E=";
            name = "groovylambda";
            publisher = "sheaf";
            version = "0.1.0";
            sha256 = "sha256-bv1TgtFUYliKCorSvlyHABAZXVrbvBdUjepzDJI3XMg=";
            name = "code-spell-checker-czech";
            publisher = "streetsidesoftware";
            version = "1.0.4";
            sha256 = "sha256-WxmOfF8s4biiJ7TLKMkhmoCQmFrSeGcP4aIz0KRygdA=";
            name = "code-spell-checker-british-english";
            publisher = "streetsidesoftware";
            version = "1.3.0";
            sha256 = "sha256-w6RNWJH8Orc3dM0iH0sFh+WdvYTThn74HJ89KTPNAUA=";
            name = "transpose";
            publisher = "v4run";
            version = "0.0.6";
            sha256 = "sha256-oz0pg3n7jJ+JNCcSnEaRioqewCS8Jg+2ifC3F1feZ14=";

This is not the only crash I’ve experienced though, I can see .tracker-extract crashes in the log, chrome_crashpad (though I don’t use Chrome, so that’s likely coming from VS Code). I’ve even had GNOME shell crash and dump core a week or two ago IIRC. I’ve upgraded NixOS in the meantime and I haven’t had a GNOME crash since. VS Code used to work fine on my system, both with a “vanilla” setup and the override with extensions.

I’m on GNOME 3, Wayland, X1 Extreme Gen 1 ThinkPad with Intel i7 and NVidia graphics. I’ve no idea what could be causing this, or what other information may be relevant to anyone willing to research this issue. Any pointers would be greatly appreciated.

Can you share the crash logs?

Also nix-channel --list and sudo nix-channel --list - nixos-rebuild --upgrade will not update your user channels.

Are you running into this? If so, this workaround fixed it for me.

1 Like

Thank you @khaled, although I can’t assume this to be a fix for the other crash issues, I’ll pursue those separately. Launching VS Code with XWayland fixed the instant crash for me.

I will note that my value of the window.titleBarStyle setting was already set to custom, so the workaround doesn’t work for me the way it seems to for others. I’ll have to stick with XWayland for now.

@TLATER I’m not sure what you mean about not updating user channels − apologies for my ignorance.

Each user on your system has a separate set of channels. When you run nix-channel --list with your user, you can see the one your user is using.

If you use nix-env to install software, use nix-shell for shells, or use home-manager without the NixOS module, none of that software will ever be updated if you only use nixos-rebuild switch --upgrade or --upgrade-all to update.

I was wondering if the crashes were maybe because of some version mismatch somewhere in the graphics stack or such, if you happened to install those applications through something other than environment.systemPackages.

In fact, --upgrade will only update the nixos channel of your root user, your unstable channel is never updated currently, for that you need --upgrade-all. Perhaps your applications are from unstable and something weird has happened?

I’d recommend instead of using the --upgrade flag to manually update channels so you don’t run into these edge cases. --upgrade is kind of a footgun, like so many other channel-related features:

nix-channel --update      # To update what `nix-env`, `nix-shell`, etc. will install
sudo nix-channel --update # To update what `environment.systemPackages` will install
sudo nixos-rebuild switch # To update the actual system (not software currently installed with `nix-env`)
# nix-env --upgrade       # If you have things installed with `nix-env`, be aware of its limitations if you do this: https://stop-using-nix-env.privatevoid.net/ 

Thank you @TLATER for such a thoughtful response.

I use neither nix-env nor home-manager. However, I do use nix-shell -p all the time to try software out. Unless nix-shell -p is some kind of exception to what you talked about, I’m surprised to say that my experience does not match your explanation.

Despite never updating user channels since switching to 23.05 and only ever using nixos-rebuild switch --upgrade to upgrade the system, I’ve never run into issues with software installed with nix-shell -p being out of date. Quite the opposite: I noticed Nix downloading software I’ve used previously via nix-shell -p (e.g. chromium) even though I have not invoked the garbage collector in between. I attributed this to newer versions being released in the meantime, which indeed seems to be the case.

Screenshot from 2023-10-29 19-04-21

Some sadness about the status-quo

Thank you for the warnings regarding channels and nix-env. I’ve come across them elsewhere as well. Unfortunately, the status quo of Nix(OS) leaves me very unclear about which features are safe to use and recommended by the community. It seems that everything is either deprecated (channels) or experimental (flakes). The CLI is far from intuitive, leaving me guessing which parts of the vast feature set are actually well-integrated and designed to work with one another.

Despite the extensive documentation, many sources are either outdated or shy away from the (seemingly better thought out) experimental features. Sadly, understanding all these components well enough to use them effectively seems to require prohibitively large time investments, at least for the time being.

Interesting, because the actual script really does only go over root’s channels: https://github.com/NixOS/nixpkgs/blob/1a3c95e3b23b3cdb26750621c08cc2f1560cb883/pkgs/os-specific/linux/nixos-rebuild/nixos-rebuild.sh#L325

I was wrong about that partially though, looks like it will also update channels besides nixos these days, if they are marked for doing so by upstream, so your unstable channel would not be outdated.

I have no idea why nix-shell isn’t showing this behavior though.

Re the status quo

Non-flakes nix has footguns many of us have had to deal with, so we pre-warn those learning it now. Flakes have much fewer footguns, but due to the circumstance of it being such a comprehensive redesign it’s really hard to merge.

If you’re running up against the various UX issues a lot, I believe flakes are very usable without actually being particularly risky. Here’s a thread from yesterday asking about this problem: Is there a stable path for NixOS or is this all still an experiment?

The documentation story remains rocky. It’s a chicken-and-egg problem exacerbated by NixOS being rather unique and therefore many things just not working out of the box. It’s quite frankly amazing to me that the community is growing at the pace it is - it’s awesome, I believe there’s a decent chance we’ll make it through the growing pains.

1 Like