Repository navigation
[Bug] WebKitGTK dmabuf renderer core dump #2338
Description
Describe the bug
After applying the libsystemd fix (#2335) and the GStreamer plugin path fix (PR #2176), the Buzz Desktop AppImage still crashes with a core dump on launch on systems using Intel Mesa graphics with rootless XWayland (e.g. KDE Plasma on Wayland with Intel iGPU). The process starts, prints its log lines, then dumps core.
Setting WEBKIT_DISABLE_DMABUF_RENDERER=1 prevents the crash and the app launches and renders correctly.
To Reproduce
- On a system with Intel Mesa graphics + rootless XWayland (e.g. Garuda Linux / Arch with KDE Plasma Wayland, Intel RPL-S iGPU, Mesa 26.1.5)
- Extract the AppImage and apply the libsystemd + GStreamer fixes (per [Bug]
fix-appimage.shdoesn't remove bundledlibsystemd.so.0— AppImage crashes on distros with newer systemd (Arch, Fedora 41+, etc.) #2335 and fix(desktop): make Linux AppImage GStreamer work on non-Debian distros #2176) - Run the extracted AppRun:
./AppRun - Buzz starts, prints log lines, then crashes with a core dump (no window appears)
Expected behavior
Buzz Desktop should launch and render its window without crashing.
Supporting Material
Without WEBKIT_DISABLE_DMABUF_RENDERER=1:
buzz-desktop: persisted identity pubkey 47a52a04ae052e0cb5663d6523cc1324d22f9ed962e1f428fb83668611563882
buzz-desktop: media proxy listening on 127.0.0.1:39387
buzz-desktop: repos dir resolved at boot — no configured override, REPOS is the default real dir
timeout: the monitored command dumped core
With WEBKIT_DISABLE_DMABUF_RENDERER=1:
buzz-desktop: persisted identity pubkey 47a52a04ae052e0cb5663d6523cc1324d22f9ed962e1f428fb83668611563882
buzz-desktop: media proxy listening on 127.0.0.1:40347
buzz-desktop: repos dir resolved at boot — no configured override, REPOS is the default real dir
App runs correctly — WebKitWebProcess starts, window renders at full size (2560x1048, maximized), no crash.
The GDK_BACKEND=x11 hardcoded in the AppRun hook (linuxdeploy-plugin-gtk.sh) forces XWayland. The dmabuf renderer crash does not occur with GDK_BACKEND=wayland, but Wayland fails with eglMakeCurrent failed (which is why the AppRun hook hardcodes x11 — see tauri#8541).
Environment
- OS: Garuda Linux (Arch-based), KDE Plasma on Wayland
- GPU: Intel RPL-S (integrated), Mesa 26.1.5
- Display server: Wayland with rootless XWayland (
Xwayland :1-rootless) - WebKitGTK: 2.52.5 (both bundled and system)
- Buzz version: 0.4.22 (AppImage, amd64)
Additional context
This crash happens after the libsystemd (#2335) and GStreamer (PR #2176) fixes are applied. Without those fixes the app crashes even earlier, so the dmabuf issue is masked until the other two are resolved.
The WEBKIT_DISABLE_DMABUF_RENDERER=1 env var is a well-known workaround for WebKitGTK dmabuf renderer crashes on certain GPU/driver/compositor combinations. It forces WebKitGTK to use the older shared-memory rendering path instead of dmabuf buffers.
Suggested fix: add export WEBKIT_DISABLE_DMABUF_RENDERER=1 to the apprun-hooks/linuxdeploy-plugin-gtk.sh hook in the AppImage (or to fix-appimage.sh as a post-build patch), since the GDK_BACKEND=x11 XWayland path already limits rendering to X11 — the dmabuf renderer provides no benefit on this codepath and only risks crashes on Mesa-based GPU setups.
Alternatively, the fix-appimage.sh script could detect Mesa/Intel and set the env var conditionally, but since the dmabuf renderer offers no advantage on the XWayland path (it exists for Wayland zero-copy page flips, which aren't used when GDK_BACKEND=x11), setting it unconditionally is safe.
Related: #2335 (libsystemd), #2176 (GStreamer plugin path), #2315 (LD_LIBRARY_PATH leak).
Activity
bealmot commentedon Jul 23, 2026
Data point from AMD: on RDNA4 (RX 9060 XT, Mesa 26.1.2, Plasma 6.6.5) there is a similar-looking but different-root failure — no core dump; the window opens but stays invisible/transparent, and
WEBKIT_DISABLE_DMABUF_RENDERER=1does not help. Root cause there is WebKitGTK 2.52's Skia GPU path on non-conformant radv;WEBKIT_SKIA_ENABLE_CPU_RENDERING=1fixes it. Filed separately with a full isolation matrix as #2643 — noting it here for anyone on AMD hardware who lands on this issue.wpfleger96 commentedon Jul 26, 2026
🤖 @wschwab thanks for the really thorough writeup on this one — the before/after logs and the note that
GDK_BACKEND=waylandavoids the crash but dies oneglMakeCurrentwere what made it diagnosable at all.We've got a fix written (#3005) that does exactly what you suggested —
export WEBKIT_DISABLE_DMABUF_RENDERER=1in the AppImage launcher shim. But on review we caught something in the WebKitGTK source that I think makes that the wrong default, and I'd like to ask you to test a narrower variable before we ship it, if you have the time.The problem: in WebKitGTK 2.52.5 (your exact version),
WEBKIT_DISABLE_DMABUF_RENDERERdoes more than turn off Wayland zero-copy. The env check is the first statement inrendererBufferTransportMode()and it returns before the shared-memory transport gets added to the set (AcceleratedBackingStore.cpp:82-116). The empty set makescheckRequirements()return false,HardwareAccelerationManagersetsm_canUseHardwareAcceleration = false, andWebPreferencesGtk.cpp:41-49then turns off accelerated compositing and threaded scrolling. So the note in the issue that it's safe to set unconditionally because dmabuf buys nothing on the XWayland path — which I'd also assumed — doesn't hold. Upstream removed the old X11-specific renderer precisely because the DMA-BUF renderer is platform-independent and falls back to shared memory on its own, so it is doing real work even underGDK_BACKEND=x11. Setting it for every AppImage user would cost them all compositing and off-main-thread scrolling to fix a crash that hits one GPU/compositor combination.There's a narrower knob in the same function:
WEBKIT_DMABUF_RENDERER_FORCE_SHM.SharedMemorygets added to the mode on line 98, before theFORCE_SHMcheck returns on line 101 — so withFORCE_SHM=1the mode stays non-empty,checkRequirements()proceeds normally, and accelerated compositing stays on. The only thing it excludes isRendererBufferTransportMode::Hardware, which is the actual dmabuf/GBM buffer import — i.e. the thing that's blowing up on your Mesa setup. On paper that's exactly the cut we want. What I can't tell from source is whether it actually avoids your crash, and nobody on our side has Intel Mesa + rootless XWayland hardware to check — we're all on macOS. So you're the only person who can close this.If you're up for it, could you run these two against your extracted 0.4.22 tree (with the libsystemd and GStreamer fixes still applied) and say which behave how?
Mainly I want to know whether 2 launches and renders. If it does, some rough feel for whether scrolling is comparable to what you got with
WEBKIT_DISABLE_DMABUF_RENDERER=1would be a nice bonus, but the launch/no-launch answer is the decision-maker on its own.If
FORCE_SHM=1works we'll ship that instead and nobody loses acceleration. If it still dumps core, we'll go ahead and landWEBKIT_DISABLE_DMABUF_RENDERER=1with the docs corrected to say what it actually costs — a working app beats a faster one. Either way the fix will honor a value you've already set in your environment, so you'll be able to override it.Separately, #2335 is fixed on
mainnow via #2353, so the bundledlibsystemdshadowing should be gone in the next release and you shouldn't need that part of your manual patching anymore.feat(desktop): apply WebKit rendering workarounds at startup on Linux
docs: add Linux rendering troubleshooting guide (#3573)
fix(desktop): keep NVIDIA GPU rendering by disabling explicit sync in…
fix(desktop): keep NVIDIA GPU rendering by disabling explicit sync in…
COS-745: Add evidence-backed Delivery Room (#15)
feat(desktop): apply WebKit rendering workarounds at startup on Linux (…
docs: add Linux rendering troubleshooting guide (block#3573)
feat(desktop): apply WebKit rendering workarounds at startup on Linux (…
docs: add Linux rendering troubleshooting guide (block#3573)