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,

  1. Are you using custom or native titlebar ?
  2. Are you starting the application with --ozone-platform=wayland --enable-features=WaylandWindowDecorations ?
  3. Where did you install insiders from ? Snap, deb or rpm ?
  4. 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)

Commits related to this issue

Most upvoted comments

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:

#0  0x000055a6a4a2cf86 in views::View::UpdateChildLayerBounds (this=<optimized out>, offset_data=...) at ../../ui/views/view.cc:2199
#1  0x000055a6a4a2d08c in views::View::UpdateChildLayerBounds (this=<optimized out>, offset_data=...) at ../../ui/views/view.cc:2200
#2  0x000055a6a4a2d08c in views::View::UpdateChildLayerBounds (this=<optimized out>, offset_data=...) at ../../ui/views/view.cc:2200
#3  0x000055a6a4a2d08c in views::View::UpdateChildLayerBounds (this=<optimized out>, offset_data=...) at ../../ui/views/view.cc:2200
#4  0x000055a6a4a2d08c in views::View::UpdateChildLayerBounds (this=<optimized out>, offset_data=...) at ../../ui/views/view.cc:2200
#5  0x000055a6a4a2d08c in views::View::UpdateChildLayerBounds (this=<optimized out>, offset_data=...) at ../../ui/views/view.cc:2200
#6  0x000055a6a4a2d08c in views::View::UpdateChildLayerBounds (this=<optimized out>, offset_data=...) at ../../ui/views/view.cc:2200
#7  0x000055a6a4a2d08c in views::View::UpdateChildLayerBounds (this=<optimized out>, offset_data=...) at ../../ui/views/view.cc:2200
#8  0x000055a6a4a2c1e0 in views::View::SetBoundsRect (this=0x3c2400da8e00, bounds=...) at ../../ui/views/view.cc:420
#9  0x000055a6a4a2d2a2 in views::View::SetBounds (this=0x3c2403667600, x=-2147483648, y=-2147483648, height=<optimized out>, 
    width=<optimized out>) at ../../ui/views/view.cc:372
#10 views::View::SetSize (this=0x3c2403667600, size=...) at ../../ui/views/view.cc:460
#11 0x000055a6a4a452de in views::Widget::OnNativeWidgetSizeChanged (this=0x3c2400c16a80, new_size=...)
    at ../../ui/views/widget/widget.cc:1505
#12 0x000055a6a4a70097 in views::DesktopNativeWidgetAura::OnHostResized (this=0x3c2400c78fc0, host=<optimized out>)
    at ../../ui/views/widget/desktop_aura/desktop_native_widget_aura.cc:1413
#13 0x000055a6a4a70097 in non-virtual thunk to views::DesktopNativeWidgetAura::OnHostResized(aura::WindowTreeHost*) ()
#14 0x000055a6a238e25d in aura::WindowTreeHost::OnHostResizedInPixels (this=0x3c2400343700, new_size_in_pixels=...)
    at ../../ui/aura/window_tree_host.cc:688
#15 0x000055a6a2474b17 in aura::WindowTreeHostPlatform::OnBoundsChanged (this=0x3c2400343700, change=...)
    at ../../ui/aura/window_tree_host_platform.cc:217
#16 0x000055a69dceb1ce in electron::ElectronDesktopWindowTreeHostLinux::OnBoundsChanged (this=0x3c2403667600, change=...)
    at ../../electron/shell/browser/ui/electron_desktop_window_tree_host_linux.cc:57
...

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-1

Is 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:

7a8346cc11c90766fb398dd58450d2cb2a08a1a4 is the first bad commit
commit 7a8346cc11c90766fb398dd58450d2cb2a08a1a4
Author: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
Date:   Tue Nov 1 17:17:00 2022 -0400

    chore: bump chromium to 108.0.5359.22 (22-x-y) (#36163)
    
    * chore: bump chromium in DEPS to 108.0.5359.19
    
    * chore: update patches
    
    * 3859750: [linux/wayland] Added plumbing for the state of tiled edges.
    
    https://chromium-review.googlesource.com/c/chromium/src/+/3859750
    
    Also 3970920: [linux/wayland] Fixed the tiled edges for the GTK frame.
    
    https://chromium-review.googlesource.com/c/chromium/src/+/3970920
    (cherry picked from commit d3f0dbb68ac5f61074ab5f4383cb34bcc71acd7c)
    
    * chore: bump chromium in DEPS to 108.0.5359.22
    
    * chore: update patches
    
    Co-authored-by: electron-roller[bot] <84116207+electron-roller[bot]@users.noreply.github.com>
    Co-authored-by: PatchUp <73610968+patchup[bot]@users.noreply.github.com>
    Co-authored-by: John Kleinschmidt <jkleinsc@electronjs.org>

 DEPS                                                   |  2 +-
 ...d_parameter_to_linuxui_getwindowframeprovider.patch | 14 +++++++-------
 patches/chromium/blink_local_frame.patch               |  2 +-
 ...ld_do_not_depend_on_packed_resource_integrity.patch | 14 +++++++-------
 patches/chromium/disable_color_correct_rendering.patch |  4 ++--
 patches/chromium/disable_hidden.patch                  | 12 ++++++------
 ...crash_loading_non-standard_schemes_in_iframes.patch |  4 ++--
 .../chromium/mas_disable_remote_accessibility.patch    |  2 +-
 patches/chromium/printing.patch                        |  4 ++--
 ...ose_cursor_changes_to_the_webcontentsobserver.patch |  4 ++--
 patches/chromium/render_widget_host_view_base.patch    |  2 +-
 patches/chromium/worker_context_will_destroy.patch     |  2 +-
 patches/v8/build_gn.patch                              |  6 +++---
 .../do_not_export_private_v8_symbols_on_windows.patch  |  4 ++--
 patches/v8/expose_mksnapshot.patch                     |  4 ++--
 .../ui/electron_desktop_window_tree_host_linux.cc      | 18 +++++++++++++++++-
 .../ui/electron_desktop_window_tree_host_linux.h       |  1 +
 shell/browser/ui/views/client_frame_view_linux.cc      |  2 +-
 shell/browser/ui/views/client_frame_view_linux.h       |  8 ++++++++
 19 files changed, 67 insertions(+), 42 deletions(-)

Recalling something I said earlier:

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.

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,

  1. Crash due to invalid layer being passed with point focus in the application, refs https://github.com/electron/electron/issues/39449#issuecomment-1744016027
  2. Crash due to window title change
  3. Crash when initializing/rebuilding the application menu
  4. Crash on closing window with Electron >= 27

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…

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.

In 1.82 we can enable custom title bar and everything works again

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.

It actually looks like he’s linked this to an upstream issue, so it might be worth moving the conversation and debug logs over there

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 😈

#!/usr/bin/env sh
set -eu

process_string="REPLACE ME with something appropriate for your distro"
settings_path="/home/$USER/.config/Code/User/settings.json"

pgrep -f "$process_string" >> /dev/null && style="native" || style="custom"
cat <<< $(jq ".\"window.titleBarStyle\" = \"$style\"" $settings_path) > $settings_path
code "$@"

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.2

Im 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

Version: 1.82
OS: Arch Linux
WM: Hyprland

Logged both "native" and "custom" settings using

code --enable-features=UseOzonePlatform --ozone-platform=wayland  --verbose  --log debug --new-window

With "native" it crashes almost instantly. code-native.log

With "custom" one window doesn’t crash, but when I open second one it crashes both. code-custom.log

Bug still exists in:

Version: 1.84.0
Commit: d037ac076cee195194f93ce6fe2bdfe2969cc82d
Date: 2023-11-01T11:28:21.782Z
Electron: 25.9.2
ElectronBuildId: 24603566
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Linux x64 6.5.6-300.fc39.x86_64

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.

  1. titlebar=Custom: https://youtu.be/Pc1cJ9BZnVY

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.titleBarStyle set 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:

Version: 1.86.0-insider
Commit: 72cb92fdc5d08101d65d59e4b1c046d397896dd2
Date: 2023-12-12T05:36:27.172Z
Electron: 27.1.3
ElectronBuildId: 25612240
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: 11.8.172.18-electron.0
OS: Linux x64 6.6.4-200.fc39.x86_64

and the output of code-insiders --status:

Version:          Code - Insiders 1.86.0-insider (72cb92fdc5d08101d65d59e4b1c046d397896dd2, 2023-12-12T05:36:27.172Z)
OS Version:       Linux x64 6.6.4-200.fc39.x86_64
CPUs:             12th Gen Intel(R) Core(TM) i7-1260P (16 x 2540)
Memory (System):  31.06GB (15.63GB free)
Load (avg):       1, 1, 1
VM:               0%
Screen Reader:    no
Process Argv:     --enable-features=UseOzonePlatform --ozone-platform=wayland --unity-launch --crash-reporter-id cfbead22-dce7-482e-8a79-ebdcc849cc1f
GPU Status:       2d_canvas:                              enabled
                  canvas_oop_rasterization:               disabled_off
                  direct_rendering_display_compositor:    disabled_off_ok
                  gpu_compositing:                        enabled
                  multiple_raster_threads:                enabled_on
                  opengl:                                 enabled_on
                  rasterization:                          enabled
                  raw_draw:                               disabled_off_ok
                  skia_graphite:                          disabled_off
                  video_decode:                           enabled
                  video_encode:                           disabled_software
                  vulkan:                                 disabled_off
                  webgl:                                  enabled
                  webgl2:                                 enabled
                  webgpu:                                 disabled_off

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 native and custom title bar and with multiple windows too, just out of the box (Intel integrated graphics). My flags are --enable-features=WaylandWindowDecorations and --ozone-platform-hint=auto VSCode version is 1.84.1

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 custom i 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 debug flags 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 🥇

It’s not ideal for fractional scaling

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

I want to understand more about why this code was added and what it fixes

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

Version: 1.82.2
Commit: abd2f3db4bdb28f9e95536dfa84d8479f1eb312d
Date: 2023-09-14T05:51:20.981Z
Electron: 25.8.1
ElectronBuildId: 23779380
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Linux x64 6.4.15-200.fc38.x86_64

with "window.titleBarStyle": "native" (setting it to custom seems to resolve it at least for the first window) but I just updated the insiders package to the following version:

Version: 1.83.0-insider
Commit: 10765021158cf51eaf6785361598e1668f53e06e
Date: 2023-09-18T15:08:16.239Z
Electron: 25.8.1
ElectronBuildId: 23779380
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Linux x64 6.4.15-200.fc38.x86_64

and the problem seems to have gone away for me (I can also open new windows and maximise them). This is my system configuration:

Operating System: Fedora Linux 38
Desktop Environment: KDE Plasma 5.27.8
Graphics Platform: Wayland
Processors: 16 × 12th Gen Intel® Core™ i7-1260P
Graphics Processor: Mesa Intel® Graphics

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=auto flag.

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.
  • --verbose as a flag didn’t really have an effect for me.

Most stable config I found so far is this:

{
  "window.titleBarStyle": "native",
  "window.menuBarVisibility": "toggle"
}

Still crashing. ./code-exploration --verbose --ozone-platform-hint=auto --disable-features=WaylandOverlayDelegation --crash-reporter-directory ~/crash crash-maximise.zip

Also regardless of --disable-features=WaylandOverlayDelegation flag, 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.zip

[0725/095910.113322:ERROR:elf_dynamic_array_reader.h(64)] tag not found

With window.titleBarStyle=custom crash occurs when maximising new window or when maximising, then restoring, then quit.

crash-maximising-new-window.zip crash-maximise-restore-quit.zip

Version: 1.81.0-exploration
Commit: a7703202794cf4894003d6502eb196192e8e0333
Date: 2023-07-24T15:12:51.200Z
Electron: 25.3.0
ElectronBuildId: 22586453
Chromium: 114.0.5735.199
Node.js: 18.15.0
V8: 11.4.183.25-electron.0
OS: Linux x64 6.4.5-arch1-1
Off-topic

No crashes with this electron24 exploration build: https://github.com/microsoft/vscode/issues/180783#issuecomment-1555030114

Did anyone else have an electron25-flags.conf in their ~/.config directory? I had it with:

--enable-features=WaylandWindowDecorations
--ozone-platform-hint=auto

Don’t remember if I added that in myself, but I renamed it to something else. That was the culprit for me. I only got “is not in the list of known options, but still passed to Electron/Chromium.” for both options if I started on the command-line with:

code --ozone-platform-hint=auto --enable-features=WaylandWindowDecorations

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

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.

@jchv You’re definitely on the right track! The crash in your stacktrace looks the same as the UpdateChildLayerBounds one 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 😂 😂 😂

i was able to fix the issues with setting titlebar to custom coupled with removing both the electron arguments provided in the comments(ozone and enable feature one).

This means you are running it through xwayland? @SupremeDeity

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 titlebar to custom coupled 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 code

Version: 1.82.1
Commit: 6509174151d557a81c9d0b5f8a5a1e9274db5585
Date: 2023-09-08T08:41:36.199Z
Electron: 25.8.0
ElectronBuildId: 23503258
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Linux x64 6.4.15-200.fc38.x86_64

Updating 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 vscode settings -> Window: Menu Bar Visibility and reselect native (note cancel restart).It can make me open second window and not crashes

In 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 code many 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-1 on Arch and the issue persists. I am using a Ryzen 7k platform with an integrated GPU, quite a simple setup.

The configuration I tested:

--ozone-platform-hint=auto
--ozone-platform-hint=auto --disable-features=WaylandOverlayDelegation 
--ozone-platform-hint=auto --disable-features=WaylandOverlayDelegation --disable-gpu-sandbox

All of them tested with native or custom window.titleBarStyle configuration.

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 native and custom title bar and with multiple windows too, just out of the box (Intel integrated graphics). My flags are --enable-features=WaylandWindowDecorations and --ozone-platform-hint=auto VSCode version is 1.84.1

I 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:

  • opening vscode instance 1, connected through ssh with machine x
  • opening vscode instance 2, connected through ssh with machine y
  • maxime windows 2 -> crash
  • automatically re-opening the two windows
  • instance 1 can connect to machine x
  • instance 2 CANNOT connect to machine y, giving the error "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 %F

Happy to provide more information, if necessary.

Vscode version:

Version: 1.83.1
Commit: f1b07bd25dfad64b0167beb15359ae573aecd2cc
Date: 2023-10-10T23:45:31.402Z
Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Code/1.83.1 Chrome/114.0.5735.289 Electron/25.8.4 Safari/537.36

I’m not really sure why, the custom workaround 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:

"apc.electron": {
    "frame": false
}

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") with

code --enable-features=UseOzonePlatform --ozone-platform=wayland  --verbose  --log debug --new-window

I 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)

[0909/195219.705374:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[0909/195219.706398:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[0909/195219.707036:ERROR:elf_dynamic_array_reader.h(64)] tag not found

window.titleBarStyle=custom allows VSCode to be launched but trying to open another window of VSCode causes it to crash.

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:

  • Open a terminal
  • press Cmd + w (tabbed windows)
  • run vscode
  • each window opens as a tab

It does not work:

  • windows opens side to side

code --enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=wayland

@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.

You 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:

@.***(https://github.com/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.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

Latest vscode works on sway, with these settings:

window.titleBarStyle=custom code --enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=wayland

Adding a working data point here:

$ uname -a
Linux ackerleytng-computer 6.6.7-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 14 Dec 2023 03:45:42 +0000 x86_64 GNU/Linux
$ sway --version                                                                                
sway version 1.8.1
$ codium --version   
Warning: 'enable-features' is not in the list of known options, but still passed to Electron/Chromium.
Warning: 'ozone-platform-hint' is not in the list of known options, but still passed to Electron/Chromium.
1.85.1
08e6c15293922dd53a864bb041be381322fee401
x64
$ cat ~/.config/codium-flags.conf
--enable-features=UseOzonePlatform,WaylandWindowDecorations,WebRTCPipeWireCapturer
--ozone-platform-hint=auto
$ cat ~/.config/VSCodium/User/settings.json     
{
    "window.titleBarStyle": "custom"
}

I can confirm crashing on:

  • debian 12
  • code 1.84.1
  • radeon RX 6600 (oss driver)
  • custom menubar
  • vscode --enable-features=WaylandWindowDecorations --disable-features=WaylandOverlayDelegation --ozone-platform-hint=auto first instance working, second instance crashes both (segfault)

When running on 1.83.1 I notice

  • running with "window.titleBarStyle": "native", means application will turn on then immediately off.
  • running with "window.titleBarStyle": "custom", allows me to run a single instance (in full screen, being on hyprland)
  • starting FIRST application with "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

[1026/132047.078769:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[1026/132047.079482:ERROR:elf_dynamic_array_reader.h(64)] tag not found

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 replace code to 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 code build.

About
Version: 1.82.0
Commit: 8b617bd08fd9e3fc94d14adb8d358b56e3f72314
Date: 2023-09-08T15:00:07.036Z
Electron: 25.6.0
ElectronBuildId: undefined
Chromium: 114.0.5735.134
Node.js: 18.15.0
V8: 11.4.183.23-electron.0
OS: Linux x64 6.4.12-arch1-1

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.3 or 1.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=custom allows launching as others have confirmed. More interestingly I can successfully launch code when using GNOME with window.titleBarStyle=native.

Edited: Apologies, my previous revisions of this comment were incorrect. I’ve updated it so the information above holds true.