Google Chrome 151+ Crashes on KDE Plasma X11: The appmenu-gtk-module Fix

A few weeks ago, I wrote about a frustrating Google Chrome crash on Debian-based Linux systems: How to Downgrade Google Chrome on Debian Linux (Fixing Crashpad & Segmentation Fault).

At the time, downgrading Chrome from 151 to 150 was the practical workaround to get back to work without browser interruptions.

However, after digging much deeper into the crash with debuggers and configuration isolation, I eventually discovered the actual underlying trigger on my system.

It wasn't NVIDIA proprietary drivers.
It wasn't GPU hardware acceleration.
It wasn't a corrupt Chrome user profile.
It wasn't a broken Chrome package installation.

It was KDE's appmenu-gtk-module.

The Symptoms

Here was my active Linux desktop environment setup:

• OS: Linux (Debian-based) with KDE Plasma
• Session: Plasma X11 session
• Browser: Google Chrome 151+ (installed from Google's official .deb package)
• Graphics: NVIDIA + Intel hybrid graphics

The first problematic Chrome version I encountered was:

151.0.7922.173

Subsequent releases—including Chrome 152 and Chrome 153—continued to crash immediately upon launch.

Launching Chrome directly from a terminal produced errors similar to:

[ERROR:third_party/crashpad/crashpad/snapshot/elf/elf_dynamic_array_reader.h:64]
tag not found

Segmentation fault (core dumped)

The repeated Crashpad messages made the issue look like an internal Crashpad snapshot defect, but that turned out to be completely misleading.

Downgrading Chrome Worked — But It Wasn't the Real Fix

Initially, Chrome 150 worked perfectly when run as a standalone extraction:

/tmp/chrome150/opt/google/chrome/chrome \
    --user-data-dir="$HOME/.config/google-chrome-150"

Chrome 150 launched normally without any hiccups. Chrome 151+, however, crashed instantly—even when supplied with --disable-gpu.

I also tested with a completely fresh, empty Chrome profile directory. It still crashed with a core dump. That ruled out the usual user data directory or extension corruption explanation.

Investigating the Segmentation Fault with GDB

To pinpoint the exact instruction sequence causing the crash, I attached GDB (GNU Debugger) to the Chrome process.

The crash stack trace consistently showed up inside GTK and GLib event loop routines:

libdouble-conversion.so.3
libgio-2.0.so.0
libglib-2.0.so.0
g_main_context_iteration()

This was a pivotal clue: the failure was happening in the GTK/GLib initialization and event dispatch path rather than deep inside Chrome's Blink rendering or GPU graphics stack.

I systematically tested various workarounds:

• --disable-gpu
• --disable-crash-reporter
• Fresh isolated Chrome profile directories
• Adjusting different GTK theme settings
• Adjusting different Qt environment settings
• Disabling WebGPU flags
• NVIDIA driver reconfigurations
• Swapping system libraries vs. Chrome's bundled libraries

None of those solved the startup crash. Eventually, the KDE/GTK integration layer became the obvious place to isolate.

The Crucial Configuration File: ~/.config/gtk-3.0/settings.ini

On my system, KDE Plasma automatically manages the GTK 3 theme configuration file at:

~/.config/gtk-3.0/settings.ini

Inspecting the contents revealed the following configuration section:

[Settings]
gtk-theme-name=Breeze
gtk-shell-shows-menubar=1
gtk-modules=window-decorations-gtk-module:colorreload-gtk-module:appmenu-gtk-module

Notice the gtk-modules directive. Three separate GTK modules were being dynamically injected into every GTK3 process on startup:

1. window-decorations-gtk-module
2. colorreload-gtk-module
3. appmenu-gtk-module

Rather than deleting all modules blindly, I tested each module individually.

Testing the GTK Modules: Controlled Reproduction

I edited ~/.config/gtk-3.0/settings.ini to isolate each module:

Test 1: Window decorations only

gtk-modules=window-decorations-gtk-module

Result: Chrome launched normally!

Test 2: Color reload only

gtk-modules=colorreload-gtk-module

Result: Chrome launched normally!

Test 3: AppMenu only

gtk-modules=appmenu-gtk-module

Result: Chrome crashed immediately with Segmentation fault!

The culprit was undeniably appmenu-gtk-module.

The Clean Fix: Removing Only appmenu-gtk-module

Instead of purging your entire GTK configuration or downgrading Chrome, you simply need to remove appmenu-gtk-module from the gtk-modules line.

Step 1: Backup and Update settings.ini

Run the following commands in your terminal:

# 1. Create a backup of your current GTK3 settings
cp ~/.config/gtk-3.0/settings.ini ~/.config/gtk-3.0/settings.ini.bak

# 2. Update gtk-modules to exclude appmenu-gtk-module
sed -i 's/^gtk-modules=.*/gtk-modules=window-decorations-gtk-module:colorreload-gtk-module/' \
  ~/.config/gtk-3.0/settings.ini

Step 2: Launch Google Chrome

google-chrome

Chrome now launches instantly and stably!

• No browser downgrade required.
• No --disable-gpu compromise.
• No missing hardware acceleration.
• No loss of bookmarks or Chrome profiles.

Why Does appmenu-gtk-module Crash Chrome?

The appmenu-gtk-module package is designed to export GTK application menu bars over DBus to support KDE Plasma's Global Menu widget in top panels or title bars.

Recent Chromium and Chrome builds refactored internal GTK/GLib event dispatch loops. When appmenu-gtk-module attempts to hook into Chrome's GTK window structure during early startup, an incompatible memory dereference occurs during g_main_context_iteration(), triggering an unhandled SIGSEGV segmentation fault.

A Note About Global Menus & GTK 4

What About GTK 4?

Checking my GTK 4 configuration at ~/.config/gtk-4.0/settings.ini showed:

gtk-modules=window-decorations-gtk-module:colorreload-gtk-module

KDE did not register appmenu-gtk-module under GTK 4, so no modifications were required there. The issue is strictly isolated to GTK 3.

The Global Menu Trade-Off

If you actively rely on KDE's Global Application Menu widget for GTK applications, removing appmenu-gtk-module means those specific GTK apps will display their traditional internal menu bar instead of exporting it to the top panel. For Chrome (which does not use traditional GTK menu bars anyway), there is zero visual or functional loss.

My Verified Working ~/.config/gtk-3.0/settings.ini

For reference, here is my complete, working GTK 3 configuration with Chrome 153+ running on KDE Plasma X11:

[Settings]
gtk-application-prefer-dark-theme=true
gtk-button-images=true
gtk-cursor-theme-name=breeze_cursors
gtk-cursor-theme-size=24
gtk-decoration-layout=icon:minimize,maximize,close
gtk-enable-animations=true
gtk-font-name=Noto Sans, 11
gtk-icon-theme-name=Numix
gtk-menu-images=true
gtk-modules=window-decorations-gtk-module:colorreload-gtk-module
gtk-primary-button-warps-slider=false
gtk-shell-shows-menubar=1
gtk-theme-name=Breeze
gtk-toolbar-style=3
gtk-xft-dpi=98304

Summary

If you encountered the sudden Google Chrome 151+ crash loop on Linux with KDE Plasma X11, you do not need to stay locked to outdated browser versions. Simply check your GTK 3 configuration:

grep '^gtk-modules=' ~/.config/gtk-3.0/settings.ini

If appmenu-gtk-module is present, strip it from the modules list and enjoy the latest Chrome updates with full GPU acceleration intact.