VSCode Causing System to Crash and Require Forced Restart

Help
1

Hello all!

The Problem:

So, I have what I think to be a very strange but extremely annoying problem. What is happening is sometimes (not every time, but some times every time if that makes sense), when I open VSCode to my Python environment, my system will “soft crash.” What I mean is all command related operations stop working completely. So, my python interpreter will never load, (I used hyprland) so I cannot use keyboard shortcuts to open any applications change system volume, etc… I can still navigate through workspaces, kill applications, and even still use applications that are running; however, nothing else works. If I have a terminal window open when the system “soft crashes” I can run commands and monitor the system, but none of the commands I run are saved in the terminal history and nothing gets written to the system (I tried to write the logs to a file during the crash state but the logs never saved. I had to run the command again once I had rebooted). The last symptom is if I switch TTY (or use an open terminal session), and I sudo reboot the system, it will hang in the reboot process until I hit the physical restart button on my PC.

What I’ve Tried:

I have tried switching TTYs and checking the logs there, and I have also tried killing different applications (code, pet) to see if the problem resolves, but none of those have worked. I thought it might be some sort of race condition or loop relating to my devenv environment, but I removed it completely and the problem still persisted. I also tried disabling PyLance and Pylint in VSCode, but that didn’t work either.

Final Thoughts:

This problem seems to happen most frequently when interacting with the python interpreter. For example, I tried to create a normal venv environment in a completely new directory, and that caused the system to crash. I also had a crash occur today when trying to launch an instance of DataViewer in VSCode. So, it seems like when trying to access a python interpreter, something is happening that is causing the crash.

I can’t for the life of my figure out why though. I’ve added my system specs, OS/WM, and a short snippet from journalctl of the exact time a crash occurred. If any additional information is need please let me know, and thanks in advance!

NixOS Channel - Unstable

Hyprland - 0.53.3

VSCode - 0.108.1

Linux Kernel - 6.18.6-zen1

Logs:

These logs come from the most recent crash. The system crashed at 9:21am and these are all the logs I have in my journalctl from that time. I rebooted the system at ~9:23am.

Jan 29 09:21:06 default dbus-daemon[1035]: [system] Activating via systemd: service name=‘org.bluez’ unit=‘dbus-org.bluez.service’ requested by ‘:1.629’ (uid=1000 pid=26741 comm=“/nix/store/vgvha6gldjijkww06ihy10h9scwn6wcr-vscode”)
Jan 29 09:21:06 default systemd[1]: Bluetooth service was skipped because of an unmet condition check (ConditionPathIsDirectory=/sys/class/bluetooth).
Jan 29 09:21:06 default systemd[2008]: Started app-org.chromium.Chromium-26741.scope.
Jan 29 09:21:06 default systemd[2008]: app-org.chromium.Chromium-25565.scope: Consumed 40.889s CPU time, 1.6G memory peak.
Jan 29 09:21:31 default dbus-daemon[1035]: [system] Failed to activate service ‘org.bluez’: timed out (service_start_timeout=25000ms)
2

Is your system OOMing?

1 Like
3

Not from what I can tell. The couple times I was able to get top/btop open the memory usage looked normal, but I can double check the next time it happens. It did hit an OOM state when I ran killall code one time, but I’m not sure if that was related or just the result of the way I stopped the process.

EDIT: Confirmed not an OOM issue

4

i had a very similar experience to what you describe when my root fs malfunctioned(did not unmount, but became non-responsive) due to hardware issues triggered by certain events.

you can have journalctl -f running in a console when this happens to see logs, even though the logs wont be accessible after reboot

5

That’s a good idea. I haven’t looked into fs issues. I’ll have to check that out. I have had journalctl -f open during this soft crash event, but there were no logs. I left the window open for several minutes after the system locked but there were no logs appearing in the terminal. I will check again and leave it running for longer, maybe that will surface the issue.

6

If you really get nothing, that does sound a lot like hardware failure. Hard to pin down what exactly, it could also be memory causing a kernel panic or somesuch.

I tell this anecdote a lot, but I once traced this kind of behavior down to a loose ribbon cable for a keyboard backlight. It really could be anything.

7

I’ve had this too, presentation was exactly the same. All running applications ran but anything else would just. not. run. New terminals launched but any command would just hang.

Turns out it was git hung on pre-commit and removing .git/hooks/pre-commit* made the madness stop. It didn’t break my pre-commit (I use Lefthook), I was able to properly continue using my system normally after that.

8

but what was the mechanism with which a simple pre-commit was locking down the system like that?

was it spawning infinite processes, eating all memory, opening a billion file descriptors?

9

I didn’t get a total chance to look, once I found the issue, I killed it since by then I was deep in the “omg what is wrong with my laptop” craze of like 10 reboots. Rebooting did stop the issue until I opened the editor again (vscode at the time, don’t use it anymore though).

It wasn’t resource contention or spawning tons of rogue processes, I did look for those early. Maybe file descriptors but I didn’t look there.

10

Good idea! I’ll give that a try. I don’t use Lefthook, but I do have a git repo in this python environment and a number of Git extensions in vscode. I just had another crash today which reminded me to try your suggestion. I’ll report back on my findings.

11

So far, I’ve had the system crash one time since deleting .git/hooks/pre-commit*, though I’m pretty sure it was in a directory that I hadn’t deleted that file from yet. I will keep monitoring the issue and see if it continues to happen. However, so far so good!

12

I had it happen again recently and my old trick didn’t help me again. I think what might have been doing it was the Neovim Vscode extension, I took that out and it’s since completely stopped. Instead, I’m using the Helix for Vscode extension. Less “powerful” since it’s basic emulation but it has enough for my needs. I’ll report back if anything else crops out again. Though, with 2 instances of it happening I don’t have much to go on either.

I am using vscode official, with sync, and I’m on the latest 1.109.2 available.

13

Okay. I just had it happen twice back to back. The first time I kept using my computer for another 30mins because I didn’t need any command line related tools. However, after a restart, I launched vscode again and it happened immediately. I know I removed the git commit file so this is definitely a different problem. I am also using VSCode official with 1.109.2 release.

14

New hypothesis as I got hit again. File watchers into .direnv as that directory is huge for my as I use nix-direnv and also my venvs are in there.

# add to settings.json

  "files.watcherExclude": {
    "**/.git/**": true,
    "**/.direnv/**": true,
  },

I tried this as I saw it was hung on only python projects and it was said “attempting to identify interpretter” as it hung. This might be it this time, or so I hope.

15

Good idea! I will also give this a try and report back on my findings. Thank you again for your help in debugging this!

16

Is there’s solution to this? Experiencing the same issue

17

So far there is not. I have just made another discovery in the potential source of the problem though. What I have discovered is that it seems to be when the Python extension in VSCode tries to load the python interpreter. It is at this point that the system soft-crashes. I was able to identify this because I just did a fresh install of my Nix system (unrelated to this problem) and was loading my devenv environment for the first time. The devenv shell loads just fine (I tested this in a terminal session and was able to load python with my installed packages just fine); however, the system soft-crashes when VSCode tries to then load the interpreter (as indicated by the bottom tool bar). I have tried running VSCode from the terminal to capture the logs from the application, but have been unsuccessful thus far.

Hopefully this background information is helpful in identifying the source of this problem. I am going to continue trying solutions as I need this python environment to work.

18

I think we are on the right track with python. I have not had any more issues since I’ve implemented what I posted last. My usual stack involves:

  • Devshell
    • Python
    • UV
  • Direnv (and nix-direnv)
    • Python venv provided by layout
    • Python deps managed by UV in direnv’s venv
  • Vscode
    • Python extension
    • direnv extension

It has been normal and not had any system impacting lockups since.

19

Good to know! I have made a breakthrough myself. After locking my system up problem 10+ times, I was finally able to capture useful logs and trying several settings changes in vscode (Note: I used Google Gemini to help me understand the logs since there were so many of them). I have discovered that the source seems to be the Python Environments extension searching endlessly through the nix store (or some other large directory) for a valid python interpreter. The problem is, I haven’t found a suitable default for the extension to use. So, if you set the interpreter path for a project, it seems to work fine until it forgets it, at which point it will lock the system up again.

This is just a working theory based off the logs. I’m going to continue searching for a solution to see if I can validate this theory. Unfortunately, the logs are still quite limited so it is hard to tell exactly what is going on.

20

Hey all, I started experiencing the same issue today.

After digging a bit I ended up figuring out that it seems to be a kernel hung task caused by FUSE, which led me to GitHub - Mic92/envfs: Fuse filesystem that returns symlinks to executables based on the PATH of the requesting process. · GitHub which I had enabled.

Running a killall -9 mount.envfs actually “unhung” the system and made VSCode work again. This seems to be due to a FUSE deadlock that the python extension seems to be triggering:

and seems fixed on last envfs version (1.2.0), which hasn’t made it to nixpkgs yet apparently. For now disabling envfs has unblocked things for me.