vscode: Crash when rebuilding application menu on wayland
Extracted from https://github.com/microsoft/vscode/issues/181533#issuecomment-1565576439
Crash reason: SIGSEGV /SEGV_MAPERR
Crash address: 0x1010101
Process uptime: 142 seconds
Thread 0 (crashed)
0 code-insiders!views::View::UnregisterChildrenForVisibleBoundsNotification(views::View*) [view.cc : 2859 + 0x0]
1 code-insiders!views::View::UnregisterChildrenForVisibleBoundsNotification(views::View*) [view.cc : 2860 + 0x5]
2 code-insiders!views::View::DoRemoveChildView(views::View*, bool, bool, views::View*) [view.cc : 2702 + 0x8]
3 code-insiders!views::View::RemoveAllChildViews() [view.cc : 340 + 0x12]
4 code-insiders!electron::MenuBar::RebuildChildren() [menu_bar.cc : 234 + 0x5]
5 code-insiders!electron::RootView::SetMenu(electron::ElectronMenuModel*) [root_view.cc : 71 + 0x8]
6 code-insiders!electron::api::BaseWindow::SetMenu(v8::Isolate*, v8::Local<v8::Value>) [electron_api_base_window.cc : 0 + 0x8]
7 code-insiders!gin_helper::Dispatcher<void (electron::api::BaseWindow*, v8::Isolate*, v8::Local<v8::Value>)>::DispatchToCallback(v8::FunctionCallbackInfo<v8::Value> const&) [callback.h : 267 + 0x3]
8 code-insiders!v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) [api-arguments-inl.h : 146 + 0x3]
@Mithras can you provide the following details to help us repro the issue,
- Are you using custom or native titlebar ?
- Are you starting the application with
--ozone-platform=wayland --enable-features=WaylandWindowDecorations? - Where did you install insiders from ? Snap, deb or rpm ?
- A video recording showing the exact repro steps will be helpful.
About this issue
- Original URL
- State: open
- Created a year ago
- Reactions: 116
- Comments: 180 (8 by maintainers)
Links to this issue
Commits related to this issue
- Fix vscode crash https://github.com/microsoft/vscode/issues/184124#issuecomment-1716855998 — committed to Lillecarl/nixos by deleted user 9 months ago
- home,vscode: add workaround for crashing on wayland ref: https://github.com/microsoft/vscode/issues/184124 — committed to Guanran928/flake by Guanran928 8 months ago
- home,vscode: add workaround for crashing on wayland ref: https://github.com/microsoft/vscode/issues/184124 — committed to Guanran928/flake by Guanran928 8 months ago
- me: vscode: mitigate microsoft/vscode#184124 — committed to spikespaz/dotfiles by spikespaz 7 months ago
- home,vscode: add workaround for crashing on wayland ref: https://github.com/microsoft/vscode/issues/184124 — committed to Guanran928/flake by Guanran928 8 months ago
- Revert "me: vscode: mitigate microsoft/vscode#184124" This reverts commit 5c14d444874bfb135c5ff1c8cdfd8800886702ba. This fix didn't work. — committed to spikespaz/dotfiles by spikespaz 6 months ago
- Revert "me: vscode: mitigate microsoft/vscode#184124" This reverts commit 5c14d444874bfb135c5ff1c8cdfd8800886702ba. This fix didn't work. — committed to spikespaz/dotfiles by spikespaz 6 months ago
Well, it was not related to Chromium version after all. The bug is right here:
https://github.com/electron/electron/commit/7a8346cc11c90766fb398dd58450d2cb2a08a1a4#diff-baefd46d1d673b2cccc672cedea58414f35f81123c394b24674fe675cca3d57b
But this is weird; this doesn’t seem at all related to “rebuilding application menu”. I wouldn’t be too surprised if there are multiple bugs, but I am pretty sure this is the one that is affecting most people. And if I comment out the code in
OnWindowTiledStateChanged, the bug disappears: I can create unlimited new windows, no crashing. (I now want to make sure that my stack trace looks similar to the above, just to be sure, but I think it does, so I’m bewildered.)(Even weirder is that at electron
main, there seems to be an entirely different bug where things crash when a window is closed, but I don’t get crashes when new windows are opened, at least not that I noticed. So that might need some debugging too. But I’ll ignore it for the moment…)I want to understand more about why this code was added and what it fixes, so I can see if I can figure out what the actual underlying problem is and validate a fix for it. I am hoping that having figured out exactly the source of the problems, possibly someone with more knowledge can now help us out…
Upon trying to validate that this actually is the same bug in the OP, I am no longer 100% sure. It seems to be some kind of race condition, but in my case it seems to consistently happen during a Wayland surface configuration. Particularly:
I’m now completely confused. That makes me suspect there really must be multiple bugs at play, and it’s impossible to know how many people are being hit by this one and not the one in the OP.
All I know for sure is that VS Code has been broken since 1.78.0 for me and it hasn’t been fixed, and now I’m about as confused as ever as to what really is going on.
Can the priority of this issue be increased? It is already a second release of VSCode in a row when it is unusable under Wayland tiling managers since window is always maximized on start. No combination of options actually makes it start consistently, if you need to restart it you have to pray to be able to start it again. Admittedly not many people are using wayland tiling mangers but still it is basically broken in this scenario. Thank you!
I’ve been looking at this issue periodically to try to figure out a good angle to attack it from. None of the workarounds do anything for me, and I think it would be best to just fix the issue.
I already knew what version VS Code stopped working correctly for me; it was 1.78.0, whereas I was previously running 1.77.3. I downgraded to 1.77.3 where I am now, but unfortunately this leaves some extensions, that would be nice to have, broken, as they are unwilling to start on this now-old version.
Unfortunately, this doesn’t narrow things down much. VS Code 1.77.3 reports that it is running on “Electron 19.1.11”, a version of Electron that doesn’t even exist. Meanwhile,1.78.0 reports “Electron 22.4.8”, a leap of several major versions. Can we go narrower?
It turns out that getting VS Code started enough to repro the issue doesn’t require the native module NAPI versions to match, so it turns out it doesn’t take that much effort to go narrower. But first, I wanted to know if I could definitively say that Electron was the issue here, and that the VS Code version didn’t matter. I am using Nix/NixOS so I wrote a Nix flake that lets me test this. Indeed. If I ran vscode 1.77.3 in vscode 1.78.0’s electron shell, suddenly, it started to break on new window creation. And if I ran vscode 1.78.0 in vscode 1.77.3’s electron shell, it did not. Obviously, the app will not entirely work this way, for a variety of reasons, but it at least helps confirm this line of thinking.
Last night, I started working out how to narrow things down further. VSCode starts enough inside of a plain upstream Electron binary to allow us to repro the issue, so we can test using any of those. I extended my Nix flake and was able to narrow it down to having been broken between 21.4.4 and 22.0.0. (If anyone wants to follow along, you’ll need the Nix package manager and this flake. Plop it in a new empty folder and run e.g.
NIXPKGS_ALLOW_INSECURE=1 NIXPKGS_ALLOW_UNFREE=1 nix run --impure .\#vscode_1_77_3_in_electron_22_0_0. Yes, it is a damn mess. But, I wasn’t trying to make something elegant. After it starts, create enough new windows and it should explode.)Unfortunately, being a major version gap, this does mean that there’s probably quite a lot of changes to scale. However, it does give a potential basis for doing a proper bisect, since we can just run the compiled 1.77.3 on each Electron version. So tonight, I’m going to try to figure out if I can reasonably rig a setup for building Electron and see just how many bisect steps it would take to narrow it down to a specific commit. I’m expecting that it might just break on a Chromium upgrade, at which point it will wind up being a more complicated bisect, but hopefully we can get lucky and it’s clearer than that.
Very same issue here on Arch; using custom titlebar works just for the first window, and other instances crash.
AUR package:
visual-studio-code-bin 1.83.1-1Is everybody on Wayland affected by this issue ? If so, this issue should in HIGH PRIORITY. Personally, I have nothing more to add to this issue, I think every log have already been uploaded. The current process to launch VsCode is really painfull.
I’m seriously considering switching to Emacs 29 which enable native LSP (Eglot) and Wayland support (pure GTK).
Haven’t been feeling 100% but bisecting Electron is mostly waiting so thankfully it worked out OK. And this ought to be the first commit that introduced this issue:
Recalling something I said earlier:
No such luck. So now I am guessing I will need to figure out how to bisect the Chrome version as well.
there is a simple workaround - xwayland. It’s not ideal for fractional scaling but it does work.
I can confirm that setting
"window.titleBarStyle": "custom"fixes the issue.@jchv thanks for taking the time to perform the bisect in the runtime, you are right there are multiple crashes in play. So far from the logs and repro I have seen,
This is good to know, I had the same experience when setting up the repro against different Electron versions.
I was able to address 1), haven’t looked at 2, 3 and 4 yet. All of them are also tracked in https://github.com/electron/electron/issues/39449. It would be great if you can share your findings in the upstream issue so that other Electron maintainers are also aware of it.
Yep, can confirm. Switched to
"window.titleBarStyle": "custom"and no crashes so far on 1.82, but sometimes there is couple seconds lag while opening VSCode. I’m using Hyrpland window manager, would be nice to have"window.titleBarStyle": "native"back.I was unable to get a repro on my Ubuntu 22.04 with wayland setup and ended up creating Ubuntu + Sway setup. I can now repro the crash.
Yes according to the stacktraces that I observed, it appears the bug is in Electron but manifests itself in VSCode during menu & window build on startup as a race condition between threads (see a simple example of a thread race here).
Reports of different config settings, startup flags, and initial conditions “fixing” the issue are only workarounds. The reason these work (sometimes) is because they may affect the startup timing so the right threads are more probable to “win” the race.
@deepak1556 Is anyone actively working on this? I would love to see some real progress here.
edit: the Wayland situation has been pretty bad for over half a year now, and I haven’t seen a single one of the many Wayland related bugs getting fixed.
It’s not too high for me 😈
Well I’m actually crying that this is necessary… But at least I can now start multiple instances without issue.
edit: It’s not perfect. Once you change the setting while vscode is running the entire titlebar disappears 😦. A workaround for that is to first start vscode, this instance has no titlebar. Then start a second instance. This one has a working native titlebar. Then close the first instance.
Lets make that the official method of running VSCode on Wayland.
Let’s just wait until @deepak1556 has worked on a fix.
It doesn’t help to confirm the same issue over and over again.
@alex-morgun It works for you. All of this “it works for me” is unhelpful and I wish it would stop. I’m following this issue via email notifications so that I know when it’s closed, when the problem is actually fixed.
Issue stilll exists for me on NixOS with vscode 1.83.0 on Hyprland. I guess I will be staying on 1.81.1 for the foreseeable future.
As I understand, the problem is a data race in electron. It will start working, and then stop working, because the data race is inherently unpredictable.
Same as @neondeex,
"window.titleBarStyle": "custom"fixes the crash issue. Artix Linux VSCode 1.82.0 sway 1.8.1 wlroots 0.16.2Im using hyprland + nvidia on wayland and managed to fix by setting custom tittle bar to custom and using this flags --enable-features=UseOzonePlatform --ozone-platform=wayland
Logged both
"native"and"custom"settings usingWith
"native"it crashes almost instantly. code-native.logWith
"custom"one window doesn’t crash, but when I open second one it crashes both. code-custom.logBug still exists in:
Because you want to use it? I mean you can either use XWayland or not use VSCode at all until this is fixed. It’s up to you.
Happy new year! The same issue occurred in version 1.85.1. So, any progress?
I absolutely agree with what flowHater said. Having the tool you use most for coding crash up to 50 times when you try to launch it Is a horrible feeling. (edit: just to clarify, this is not an exaggeration!)
Wayland isn’t some rare edge-case, it’s the default on most linux distros. It’s honestly shocking how little attention these wayland issues have been getting.
It almost always (but not exclusively) happens when I try to maximize one of the windows. Sometimes it crashes immediately, sometimes I need to open/move/expand/collapse for a few minutes. It seems to happen more (or maybe even only) if there are a couple different folders opened. I can’t seem to repo it with only default “Welcome” tab.
It seems as though this issue has been fixed with the update to electron 27 in the 1.86 release. Just tested on Debian 12 using KWin under both Intel integrated graphics and Nvidia’s proprietary driver and experienced no crashes whatsoever.
I’m increasingly confident Electron 27 (used by VSCode Insiders) fixed the crashes I was observing, and I was even able to use my reproducer automation (KWin Window Rules to force maximization states without manually interacting with an app) to make stable VSCode (on Electron 25) not crash.
For both versions of VSCode I was able to get working again, I can confirm fractional scaling support (crisp pixel-perfect font rendering only when a window is fully contained within one monitor, that becomes slightly fuzzy while transiting between monitors). And I also tested closing/opening windows, and all of that with
window.titleBarStyleset to both"native"and"custom"(I normally use"custom"but for my crashes I never saw it make a difference).I wrote up all the details in a much longer comment on the Electron issue: https://github.com/electron/electron/issues/39449#issuecomment-1871357712
@spikespaz Were you able to observe a crash with VSCode Insiders (specifically a build new enough to have Electron 27 in Help -> About)?Nevermind, that reaction was to https://github.com/microsoft/vscode/issues/184124#issuecomment-1863388815 claiming something about non-Insiders VSCode. In that case, I agree, I don’t think the underlying problems are fixed in Electron 25 builds of VSCode (I am on 1.85.1 which uses Electron 25.9.7, and it was very easy to generate dozens of crashes, once I started using KWin Window Rules to automate maximization).
However, keep in mind most people are commenting about VSCode Insiders, which, AFAICT did fix it. Now we just have to wait a few more weeks for it to make it into VSCode stable.
I know I’ve said this several times before in this issue but the latest insiders build seems to be working fine for me now with
window.titleBarStyle: native, multiple windows maximised and non-integer display scaling (125%). Here’s the version I’m using:and the output of
code-insiders --status:Bug persist in my case. Same code version, AMD integrated GPU.
Still happening in the latest stable release.
Arch Linux, with hyprland with wayland. without setting the titlebar to
customi cannot even open VSCode, however setting it to custom allows me to open one instance per workspace. Meaning as long as i open VSCode on separate workspaces it doesn’t crash, however if it open two on the same workspace, both instances crash.This is still happening. Sad to see an issue that has been happening for months and makes the app unusable fly totally under the radar.
I asked again on the upstream Electron bug. However, that bug has been sitting untouched for over a month. I have no idea when it could be fixed.
I’m using
--ozone-platform-hint=auto --log debugflags with"window.titleBarStyle": "native"and at least it makes it usable, like 90% less crashes, but it is unacceptable in such popular app. I’m using Wayland for half a year and VSCode consistently is the only problem in my setup.Almost a year since the issue was first reported and here we are still without a fix 🥇
Are you suggesting we should work multiple hours per day on blurry text? There is no solution for wayland with fractional scaling and multiple vscode windows, period.
@jchv
Following the links in your linked commit, you end up on
Issue 1296836: Snapping window to the left on Gnome/Wayland leaves an ugly border
I was having this problem with the following VSCode configuration
with
"window.titleBarStyle": "native"(setting it tocustomseems to resolve it at least for the first window) but I just updated the insiders package to the following version:and the problem seems to have gone away for me (I can also open new windows and maximise them). This is my system configuration:
Having the same issues on all Wayland compositors I have tried (using version
1.81.1), tiling and not tiling (Sway, Hyprland, Dwl, KDE KWin and Gnome Mutter).I’m using the
--ozone-platform-hint=autoflag.I have also tried the suggestions in the comments above:
"window.titleBarStyle": "custom"or/and"window.menuBarVisibility": "hidden"made the app crash every other time at least (1st time it works, 2nd time it doesn’t and so on) and sometimes I need to restart 5 or 6 times until it works again.--verboseas a flag didn’t really have an effect for me.Most stable config I found so far is this:
Still crashing.
./code-exploration --verbose --ozone-platform-hint=auto --disable-features=WaylandOverlayDelegation --crash-reporter-directory ~/crashcrash-maximise.zipAlso regardless of
--disable-features=WaylandOverlayDelegationflag, crash occurs on startup after switching from custom to native titlebar while being maximised.crash-startup-maximised.zip wayland-debug.log
Electron 25 crash every time on window maximising with
window.titleBarStyle=native. crash-titlebar-native.zipWith
window.titleBarStyle=customcrash occurs when maximising new window or when maximising, then restoring, then quit.crash-maximising-new-window.zip crash-maximise-restore-quit.zip
Off-topic
No crashes with this electron24 exploration build: https://github.com/microsoft/vscode/issues/180783#issuecomment-1555030114
Those are the flags to run X apps in Wayland.
By removing those you are running vscode on X, so of course you don’t have the issues presented.
You’ll probably have some.other issues like blurry text though.
Ps: Having this same issue on Hyprland
@jchv You’re definitely on the right track! The crash in your stacktrace looks the same as the
UpdateChildLayerBoundsone here (Looks like it’s in Chromium function here? 🤷). Based on the multiple stacktraces that I saw, it’s likely that there are a few different paths that can cause a similar crash on startup under Wayland. Given the probability of the bug triggering most of the time, but not always… I suspected that these might be race conditions also, so It’s good to see you validating that hypothesis. It’s also likely that there are multiple threads at play during the crash, which can make things a bit more confusing.EDIT:
Some of my own speculation :thinking: ...
Although I’m not a Chromium developer, nor am I that proficient in C/C++ these days… my hunch is that these bugs all may have a common root cause: null or invalid pointers being used in all the functions where we have found crashing & stacktraces with
SIGSEGV. It may be likely that whichever thread is supposed to set up the (windows, layers, menus, views, etc…) is slower in most of our trial runs than the threads trying to access or update those things through pointers. Sometimes, that thread “wins” the race and the pointers are valid (no crash), but most of the time that thread “loses” the race and the other threads try to access an invalid or null pointer (crash). It seems that this is during Chromium + Electron startup, and some basic assumption is not being satisfied (things are not set up completely yet), before those other function calls in the other threads try to access those things.My naïve notion for how to fix this logically: Satisfy the preconditions & assumptions made by those other functions. That is to say: Make sure things are guaranteed to be set up and the pointers are valid before those functions try to access them.
Ok you got me, here i come on the hack train
Can already imagine the bash script
Jq replace to custom if no vs code running alreadu VS Code run Jq switch back to native
The level of hackery is too high for me I’m afraid 😂 😂 😂
Ah i checked and thats why its running correctly. I feel like a clown now.
Ok so, with Hyprland(Wayland) on Arch Linux, i was able to fix the issues with setting
titlebartocustomcoupled with removing both the electron arguments provided in the comments(ozone and enable feature one).Without using custom titlebar, VSCode will not even open fully and crash and if i use custom titlebar with conjunction to the electron flags then i can open only a single VSCode instance, anymore would crash. Please try checking if the same works for you.
Flag using only
--ozone-platform-hint=auto, maximizing crashes vs codeUpdating to 1.82.1 still doesn’t work for me.
As a temporary solution,I startup with
"window.titleBarStyle": "custom"parameters by edit.config/Code/User/settings.json,then i will edit vscodesettings->Window: Menu Bar Visibilityand reselectnative(note cancel restart).It can make me open second window and not crashesIn 1.82 we can enable custom title bar and everything works again
With version 1.82 I can’t even use VSCode, it crashes every time. Downgraded to 1.81.1 and now it’s in a working state again, so like 1 out of 10 times it will crash. I’ve used VSCode on 3 devices with AMD iGPU, AMD GPU and Nvidia GPU, it crashes exactly the same on each.
After some more testing on Wayland… I can say that after restarting
codemany times, eventually it does start up even when"window.titleBarStyle": "native"is set. There are multiple different codepaths that might be shown in stacktrace when it crashes, the ones I posted above being a few.It seems like this might be related to a race condition between threads during startup. Eventually after enough tries, the right thread will “win” and then Code works properly until the next quit & startup when it will probably crash again until the right race condition is met.
@musakarimli Are you testing on 1.88?
It got an Electron 28 update which fixed further Wayland issues.
https://wiki.archlinux.org/title/Wayland#Environment_variable
Also a heads up, Electron 28 allows for using Env vars to enable the Wayland backend, so you can stop VSC throwing warnings into STDERR if you were doing it through flags til now.
It still crashes sometimes IME, but not nearly as often, so at least it’s actually usable.
I just tried with the latest
visual-studio-code-bin 1.84.1-1on Arch and the issue persists. I am using a Ryzen 7k platform with an integrated GPU, quite a simple setup.The configuration I tested:
All of them tested with
nativeorcustomwindow.titleBarStyleconfiguration.All those permutations just fire the segfault.
For me, after installing v1.84.1, I can now get
"window.titleBarStyle": "native"to work on Wayland (including multiple windows maximised), if I also pass the flag--disable-gpu-sandbox.Hi, yesterday I updated/upgraded my pc to latest Arch packages and GNOME 45.1 and in my case, VS Code now works both with
nativeandcustomtitle bar and with multiple windows too, just out of the box (Intel integrated graphics). My flags are--enable-features=WaylandWindowDecorationsand--ozone-platform-hint=autoVSCode version is1.84.1I have a similar issue. When I open more than one window and I click on maximize, the behaviour is an instant crash (sometimes works, sometimes it’s a crash, I’m unable to find a correlation as now, unfortunately).
Moreover, I noticed a strange thing when working with ssh. I briefly describe the setup, and then the outcome:
"Timed out while waiting for the local startup lock"Running on ubuntu 23.04,Wayland, using
"Dialog style": "custom", and this custom config on.desktop:Exec=/usr/share/code/code --enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=wayland %FHappy to provide more information, if necessary.
Vscode version:
I’m not really sure why, the
customworkaround was working for me. But now I’m seeing the exact opposite. Having"window.titleBarStyle": "custom"was causing VSCode to insta-crash. Now I’ve set it to"window.titleBarStyle": "native"and I can open a single window. (Opening a second window continues to cause both to come crashing down.)@pgawron Unfortunately it still crashes for me.
The thread to follow is this one: https://github.com/electron/electron/issues/39449
@pgawron does it work also for multiple code instances?
In an effort to hide the title bar in sway-wm, I’ve gotten
"window.titleBarStyle": "native"to work by using the APC Customize UI++ extension with the following configuration:I’m running VS Code version 1.82.2. But I’m unsure if this’ll help people who still want any sort of title bar.
I only had this issue when clicking maximize to quickly while vscode is still loading. (And rarely seemingly randomly in other circumstances). However now with the newest version it always happens if I have more than one vscode window open and want to click maximize on e.g. a newly opened one.
When I run VS Code (on Fedora 38 with Wayland session and
"window.titleBarStyle": "custom") withI don’t have any problem and get 2 windows. But second window is small and when I click
Maximaze Window, both windows are crashing down.(Maximizing on one window doesn’t create any problem)
The log of first window (the second window runs detached and don’t print log while crash)
window.titleBarStyle=customallows VSCode to be launched but trying to open another window of VSCode causes it to crash.@deepak1556 https://github.com/electron/electron/issues/39449
I am pretty sure there are multiple Wayland crashes being talked about in this thread (and many more in the thread that this one is extracted from), some of them fixed in the current 1.88.
If you still experience crashes, attaching debug logs and other information from 1.88 would probably be helpful to the developers.
I still have uncommon crashing issues, but it’s no longer 100% reproducible.
With “window.titleBarStyle”: “native,” everything runs smoothly. However, with the “custom” title bar style, opening and maximizing new windows occasionally leads to crashes. It’s not as frequent as before, but it’s still annoyingly frequent.
It seems to be fix for me too. Thx so much.
I found how it works in SwayWM:
It does not work:
code --enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=waylandYou can set your watch settings to notify only on status change.
I’m following this issue too. My fixes include custom scripts and hotkeys to directly change the titlebar setting. I can turn my “fixes” which are more like hacks into a repository if it helps temporarily. It really is just a bandage for the problem, but it works. On Tuesday, December 19th, 2023 at 11:26 PM, Jacob Birkett @.***> wrote:
Latest vscode works on sway, with these settings:
window.titleBarStyle=customcode --enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=waylandAdding a working data point here:
I can confirm crashing on:
--enable-features=WaylandWindowDecorations --disable-features=WaylandOverlayDelegation --ozone-platform-hint=autofirst instance working, second instance crashes both (segfault)When running on 1.83.1 I notice
"window.titleBarStyle": "native",means application will turn on then immediately off."window.titleBarStyle": "custom",allows me to run a single instance (in full screen, being on hyprland)"window.titleBarStyle": "custom",THEN changing to"window.titleBarStyle": "native",allows me to run multiple instances, if i turn them all off I go back to the first case in this list.So starting with custom then transitioning to native gives the “desired” behaviour, that is a hacky workaround though…
Also facing this issue. Arch Linux with Hyprland. everything opens fine, but when I move my mouse it crashes after logging
keyboard input works though, I can still navigate around with keyboard shortcuts and it all works fine until I accidentally move my mouse.
@pgawron’s solution unfortunately does not work for me, but
"window.titleBarStyle": "custom"does.I tried VScodium 1.83.0-insider x64
Window opened successfully, but crash happen on new window creation. @ai, @hyperpuncher please launch VSCode with following command:
code --enable-features=UseOzonePlatform --ozone-platform=wayland --verbose --log debug --new-window. If you use codium or insiders version replacecodeto your version name.I attach my launch logs here (seems, it not contain much useful information about crash): insiders.log
I cannot reproduce startup crash anymore with the latest archlinux
codebuild.About
KDE Wayland Intel Tigerlake
It no longer crashes on startup using either “native” or “custom” titlebar, although with “native” titlebar it now crashes on close with the “tag not found” error.
Also vs insiders build now crashes 100% of a time using “native” titlebar.
Just upgraded to 1.82, was able to start the app only with
--disable-gpu. My guess is that it’s something related to the combination of Nvidia proprietary driver (maybe) + Chromium + dmabuf still not working properly since I wasn’t able to get it working in Chromium as well.OS: Arch, Linux 6.5.2, Nvidia GeForce GTX 1650 (driver version 535.104.05), sway 1.8.1.
@phisch, @flowHater If you need fast workaround and you agree with downgrading several extensions, you can downgrade to vscode
1.77.3or1.77.2.On my Linux these versions work excellent (I use first variant).
I’m having similar behavior to @trinitronx wherein code with successfully launch without crashing very infrequently leading me to buy into the race condition theory.
When using Hyprland,
window.titleBarStyle=customallows launching as others have confirmed. More interestingly I can successfully launch code when using GNOME withwindow.titleBarStyle=native.Edited: Apologies, my previous revisions of this comment were incorrect. I’ve updated it so the information above holds true.