1.136.0: no window on Linux when appmenu-gtk-module is loaded via gtk-modules (works in 1.134.0)

- VS Code Version: 1.136.0 (commit `520fb30b2d3d324b4cb2342f6e88e2cd93751de1`, 2026-09-02T09:13:42Z, deb x64)
- OS Version: Ubuntu 24.04.4 LTS, kernel 7.0.0-30-generic, KDE Plasma 5.27.12 on **X11**
- Electron 42.10.0 / Chromium 148.0.7778.280
- GPU: Intel Raptor Lake-P UHD Graphics, Mesa 25.2.8

## Summary

Starting with 1.136.0, VS Code never opens a window on this machine. The browser process starts, forks the zygotes, GPU process and network service, and then **deadlocks — no renderer process is ever created and no window is mapped.**

The trigger is the GTK module `appmenu-gtk-module` (Ubuntu package `appmenu-gtk3-module` 0.7.6-2.1ubuntu2) being listed in `gtk-modules=` in `~/.config/gtk-3.0/settings.ini`. KDE Plasma writes that line itself, so this is the default state on a Plasma desktop with that package installed — and `plasma-workspace` depends on it, so it is present on essentially every Ubuntu/Kubuntu KDE install.

**1.134.0 starts fine with the exact same module loaded.** Both builds ship the same Chromium (148.0.7778.280) and have identical glibc symbol requirements, so the change appears to be on the VS Code side rather than an Electron bump.

## Steps to Reproduce

1. On Linux/GTK3, put this in `~/.config/gtk-3.0/settings.ini`:
```ini
[Settings]
gtk-modules=appmenu-gtk-module
```
(`libappmenu-gtk-module.so` must be installed — on Ubuntu: `apt install appmenu-gtk3-module`.)
2. Launch VS Code 1.136.0.

**Expected:** the window opens.
**Actual:** no window ever appears. The process stays alive; the main thread blocks in `anon_pipe_write` (state `D`/`S`), there is a zombie child, and no `--type=renderer` process exists. The user-data-dir only ever gets a `Crashpad` folder — VS Code's own profile directories are never created.

## Bisect

Each row is a separate launch with a clean `--user-data-dir`:

| Configuration | Window opens? |
| --- | --- |
| 1.136.0, stock config | no |
| 1.136.0, clean `HOME` | **yes** |
| 1.136.0, `XDG_CONFIG_HOME` redirected | **yes** |
| 1.136.0, binary search over 114 entries in `~/.config` | culprit: `gtk-3.0` |
| 1.136.0, `gtk-3.0` without the `.css` files | no |
| 1.136.0, `gtk-3.0` without the `gtk-modules=` line | **yes** |
| 1.136.0, `gtk-modules=colorreload-gtk-module` only | **yes** |
| 1.136.0, `gtk-modules=window-decorations-gtk-module` only | **yes** |
| 1.136.0, `gtk-modules=appmenu-gtk-module` only | **no** |
| **1.134.0**, stock config (module loaded) | **yes** |

## Ruled out

User profile and a clean profile; extensions (`--disable-extensions` and an empty `--extensions-dir` both still fail); GPU (`--disable-gpu`, `--use-gl=swiftshader`, `--use-gl=angle`); `--no-sandbox`; `--disable-crash-reporter`; proxy resolution (`--no-proxy-server`, `--proxy-server=direct://`); GIO modules and dconf (`GIO_MODULE_DIR` empty, `GSETTINGS_BACKEND=memory`); fontconfig caches; disk space; package integrity (`md5sum -c` against the dpkg manifest passes for every file).

`ELECTRON_RUN_AS_NODE=1 code -e '...'` works normally, so the Node/V8 side is healthy — the failure is in the browser/UI startup path.

## Diagnostics

Under `gdb`, the browser process takes a SIGSEGV jumping to a bogus function pointer dispatched from the GLib main loop:

```
Thread 1 "code" received signal SIGSEGV, Segmentation fault.
#0 0x0000772db9c720e0 in ?? ()
#1 0x0000772dbcb40c13 in ?? () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#2 0x0000772dbcb4925f in ?? () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#3 0x0000772dbcae17bb in ?? () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#4 0x0000772dbcae5713 in ?? () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#5 0x0000772dbcb3fe62 in ?? () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#6 0x0000772dbcae17bb in ?? () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#7 0x0000772dbcae17f5 in ?? () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#8 0x0000772dbd08145e in ?? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#9 0x0000772dbd0e0977 in ?? () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x0000772dbd080a23 in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
```

The target address is not in any executable mapping — consistent with a callback left behind by a module that was unloaded, or an ABI mismatch in the module. `si_code` alternates between `SEGV_ACCERR` and `SEGV_MAPERR` across runs, and the faulting address lands in whatever happens to be mapped at that spot (in one run, a read-only `mmap` of a fontconfig cache), but the low bits are identical run to run, so it is a consistently computed bad pointer rather than random corruption.

`strace` shows the browser process reaching the GTK/GLib startup (gsettings schemas, dconf, `kioslaverc`, font loading) and then taking the SIGSEGV; afterwards the main thread spins writing 8-byte wakeups to an eventfd/self-pipe until it blocks, which is the visible hang.

## Workaround

Remove `appmenu-gtk-module` from `gtk-modules=` in `~/.config/gtk-3.0/settings.ini`. Uninstalling `appmenu-gtk3-module` is not an option on KDE, since `plasma-workspace` depends on it. Note that KDE's System Settings can rewrite this file and reintroduce the module.

## Notes

- Not tested on 1.135.0 (download failed), so I can't say whether the regression landed in 1.135.0 or 1.136.0.
- Wayland not tested; this is an X11 session.