[Bug]: SIGSEGV in MenuBar::RefreshColorCache when creating a framed BrowserWindow with a menu on Wayland (GTK not loaded) #54594

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a bug report that matches the one I want to file, without success.

Electron Version

44.5.1 (also 46.0.0-nightly.20260929)

What operating system(s) are you using?

Other Linux

Operating System Version

AlmaLinux 8.10 (RHEL 8 family), GNOME Shell / mutter 3.32.2 on Wayland, GTK 3.22.30, glibc 2.28, x64

What arch are you using?

x64

Last Known Working Electron version

38.1.2

Does the issue also appear in Chromium / Google Chrome?

I don't know how to test

Expected Behavior

A framed BrowserWindow with the default application menu opens on a Wayland session.

Actual Behavior

The main process crashes with SIGSEGV inside new BrowserWindow(). No window opens.

This looks related to #49244, but it is a different call site. #54365 fixed the title bar path. This crash is in the menu bar path, and it still happens on 46.0.0-nightly.20260929, which includes #54365.

Testcase Gist URL

No response

Additional Information

Repro

package.json:

{ "name": "repro", "version": "1.0.0", "main": "main.js" }

main.js:

const { app, BrowserWindow } = require('electron')

app.whenReady().then(() => {
  const win = new BrowserWindow({ width: 800, height: 600 })
  win.loadURL('data:text/html,<h1>hello</h1>')
  console.log('window created, electron', process.versions.electron)
  setTimeout(() => app.quit(), 3000)
})

Run from a GNOME Wayland session (XDG_SESSION_TYPE=wayland): npx electron .

Results

38.1.2 and 38.2.0 use the same Chromium (140.0.7339.133). The only Linux change in 38.2.0 is #48309 ("set ozone platform for wayland"), which made Electron honor XDG_SESSION_TYPE=wayland. Before 38.2.0 the app ran on X11 on this machine.

A framed window without a menu works. A frameless window works (no menu bar is created). The crash needs both a native frame and a menu bar.

Stack trace (44.5.1)

gdb on RHEL 8 (8.2) cannot read the zstd-compressed sections in electron.debug, so frames were resolved from its .symtab by scanning the crashed thread's stack for return addresses. Frame #0 is a call to address 0x0.

#0  0x0000000000000000
#1  gtk::GtkCheckVersion(unsigned int, unsigned int, unsigned int)+0xb1
#2  gtk::AppendCssNodeToStyleContext(gtk::GtkCssContext, std::string const&)+0x58e
#3  gtk::GetStyleContextFromCss(std::string const&)+0x77
#4  gtk::GetBgColor(std::string const&)+0x1a
#5  electron::MenuBar::RefreshColorCache(ui::NativeTheme const*)+0x32
#6  electron::MenuBar::MenuBar(electron::NativeWindow*, electron::RootView*)+0x145
#7  electron::RootView::SetMenu(electron::ElectronMenuModel*)+0x65
#8  electron::api::BaseWindow::SetMenu(v8::Isolate*, v8::Local<v8::Value>)+0x94
    ...
    electron::api::BaseWindow::InitWith(v8::Isolate*, v8::Local<v8::Object>)+0x18
    electron::api::BrowserWindow::BrowserWindow(gin::Arguments*, gin_helper::Dictionary const&)+0x35c
    electron::api::BrowserWindow::New(gin_helper::ErrorThrower, gin::Arguments*)+0xc2

GtkCheckVersion+0xb1 returns from a call to the gtk_get_major_version stub, and the stub jumps through gtk_get_major_version_ptr, which is still null. So the GTK symbols were never loaded on this path, but MenuBar::RefreshColorCache calls into GTK anyway.

The only GTK message in the log before the crash is:

ERROR:ui/gtk/gtk_ui.cc:265] Schema org.gnome.desktop.interface does not have key font-antialiasing

(The schema on this system is from gsettings-desktop-schemas 3.32. Adding the key removes the message but not the crash.)

Suggested fix

Guard the GTK color lookup in MenuBar::RefreshColorCache the same way #54365 guarded the frame view: skip the gtk::GetBgColor path, or fall back to ui::NativeTheme colors, when GTK is not loaded or no ui::LinuxUiTheme is available.