VSCode Causing System to Crash and Require Forced Restart

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)

Is your system OOMing?

1 Like

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

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

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.

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.

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.

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?

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.

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.