deepak1556
commented
2 days ago Thanks for the detailed report, from the application logs the only thing that stands out is this failing Check failed: g_pipe_pid == getpid() which could be from the child process being killed while still not finishing the fork calls (not sure)
For the bisect, we also maintain a node.js based CLI tool vscode-bisect that automatically downloads and runs previous VS Code insiders and asks for each build if the issue reproduces. It takes up to 8 steps to find exactly the build that caused the regression.
Steps:
- install node.js (if not yet done)
npx --yes @vscode/vscode-bisect@latest- follow the instructions until you found the offending build (its fine to leave the commit empty)
- report back the commit range in this issue
As for next steps, VSCode being a multi process application it would help to know which type of process is consuming high cpu to debug this issue further. From htop or any another process monitor can you capture the full commandline of the offending process. Based on your description it hints like the main process, would be good to confirm.
Hello,
Versions of VSC after 1.90 are freezing/failing to launch with 100% CPU load and must be manually stopped.
Description
I recently installed Debian Testing (Trixie) w/KDE on a new Chuwi Hi10 X1 tablet (Intel n100 w/8 GB RAM). I followed the installation instructions to add the keys and repositories to apt and installed VSC, using likely the latest 1.95 version. However, when I tried to launch VSC, there was no response in the GUI and
htopshowed thecodeprocess consuming 100% of one CPU core. I force killed the process and was able to get the VSC window to appear. The GUI was responsive until I tried clicking on the menu bar or if I tried creating a file from the explorer tab, at which point it would lock up and the process would go back to 100%. Kwin dialogs eventually started appearing stating that the process was not responding, but trying to stop it didn't work. The only way to recover was to reboot the PC.Pinpointing the Version
To figure out whether this was an OS problem or a VSC version problem, I had to find an older version of VSC which ran without the issue.I started installing old versions of VSC from the .deb files, launched them, confirmed if they ran, and then uninstalled that version and proceeded on to the next one to pinpoint which version introduced this behavior/bug. Actually, I started with Codium and then returned to VSC.
The only other notable difference was that in 1.90 the GUI/Electron app would appear and freeze immediately, with the "Explorer" tab progress indicator forever running from left to right.
Additional Hardware/Software Details
I would not normally use Debian testing, but I needed a newer kernel to support the hardware.
linux 6.11.9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.11.9-1 (2024-11-17) x86_64 GNU/LinuxIn addition, I've set up maliit-keyboard as a virtual keyboard. fcitx was also installed to support additional east Asian language support during the installation. I think this is worth mentioning because I do see significant improvements to accessibility features from 1.90 release notes which might be causing the lock-up when interacting with the host OS.
Logs
I'm attaching a couple things:
journalctl --since '15 min ago' immediately before invoking thecode` command until after trying to force close vsc.2024-12-01-journalctl-vsc3.txtcode --disable-extensions --verbose > 2024-12-01-code-verbose-pipe.txt2024-12-01-code-verbose-pipe.txt. This .txt was captured at another attempt until I was able to forcibly terminate and kill the process after about 3 attempts.Next Steps?
At this point, I'm not sure what would be useful to maintainers to help figure out what is going on.
Please let me know if there is something more useful I should include.