Buzz crashes when switching community

[rolznz]

Describe the bug
Every time I click on a different community the app crashes.

Steps to reproduce

1. Add 2 communities
2. Switch between them
3. Buzz fully crashes

Expected behavior
No crash

Version and platform
Find your version at the bottom of the Settings sidebar. Write "unknown" if you can't determine it.

• Buzz version: 0.5.0 (installed via .deb)
• OS: Ubuntu 24.04.4 LTS

Logs / additional context
Paste any relevant logs, error messages, or screenshots here.

(WebKitWebProcess:37370): GStreamer-CRITICAL **: 14:52:19.199: gst_value_set_int_range_step: assertion 'start < end' failed

(WebKitWebProcess:37370): GStreamer-CRITICAL **: 14:52:19.199: gst_value_set_int_range_step: assertion 'start < end' failed
Segmentation fault (core dumped)

[Chessing234]

opened troubleshooting notes in #3922 — the log matches a webkit/gstreamer teardown race on community remount. try .deb/.rpm or --safe-rendering and clearing ~/.cache/gstreamer-1.0 while #2694 / #2804 land fuller GST fixes.

[HolgerHatGarKeineNode]

Also happens on Arch Linux, so it isn't Ubuntu-specific.

Repro: Buzz 0.5.2, AppImage (extracted tree), Arch Linux, X11 + NVIDIA. Crashes on the first community switch, every time — 9 SIGSEGVs today, all with the same top frame.

Neither workaround helps here:

• --safe-rendering (i.e. WEBKIT_DISABLE_DMABUF_RENDERER + WEBKIT_DISABLE_COMPOSITING_MODE, feat(desktop): apply WebKit rendering workarounds at startup on Linux #3271) — still crashes on the first switch, byte-identical stack. Core confirms the flag was active (Command Line: buzz-desktop --safe-rendering).
• Clearing ~/.cache/gstreamer-1.0 — same, next switch crashed with an identical stack.

Probably not bundled-lib shadowing either. I reran the same binary against Arch's system WebKitGTK 2.52.5 instead of the bundled Ubuntu build (LD_LIBRARY_PATH shim ahead of the binary's RUNPATH=$ORIGIN/../lib). Still segfaults on the community switch — two different WebKit builds, same action, same shape of stack. That points at the community remount teardown rather than #2560 / #3494.

Stacks (UI thread, SIGSEGV / SEGV_MAPERR in both cases)

Bundled WebKit — 7 dumps, byte-identical offsets (including the --safe-rendering run):

#0  libwebkit2gtk-4.1.so.0 + 0xfd69b2
#1  libwebkit2gtk-4.1.so.0 + 0xe1f9eb
#2  libwebkit2gtk-4.1.so.0 + 0xf6269f
...
#10 libjavascriptcoregtk-4.1.so.0 + 0x1882405
#15 g_main_context_iteration
#16 gtk_main_iteration_do
#18 tao::platform_impl::platform::event_loop::EventLoop<T>::run
#19 buzz_lib::run

System WebKitGTK 2.52.5:

#0  /usr/lib/libwebkit2gtk-4.1.so.0.21.9 + 0x1cec04e
#1  /usr/lib/libwebkit2gtk-4.1.so.0.21.9 + 0x1c85a6a
#2  /usr/lib/libwebkit2gtk-4.1.so.0.21.9 + 0x14cf5f6
...
#7  /usr/lib/libjavascriptcoregtk-4.1.so.0.10.13 + 0x22e591f
#11 g_main_context_iteration
#12 gtk_main_iteration_do

Note: no GStreamer frames appear in any trace on this machine, unlike the reported log — the GStreamer-CRITICAL lines may be incidental rather than the cause.

No working workaround found. Happy to run a debug build with symbols if that would help narrow the frame.

(Edited: an earlier version of this comment claimed --safe-rendering does not exist. That was wrong — I misread concatenated Rust .rodata in strings output as an asset name. The flag is real and shipped in 0.5.2 via #3271; it is now tested above.)

[HolgerHatGarKeineNode]

Follow-up: also reproduces with a debug build of main (not just the 0.5.2 AppImage), on Arch, against the system WebKitGTK 2.52.5 — crashing at the same library offset as my earlier shim run (libwebkit2gtk-4.1.so.0 + 0x1cec04e). So it is neither a packaging artifact nor specific to the WebKit version shipped in the AppImage.

Rust side is symbolized; everything below gtk_main_iteration_do is WebKit/JSC without symbols:

#0  libwebkit2gtk-4.1.so.0 + 0x1cec04e
#1  libwebkit2gtk-4.1.so.0 + 0x1c85a6a
#2  libwebkit2gtk-4.1.so.0 + 0x14cf5f6
#3  libwebkit2gtk-4.1.so.0 + 0x1a56762
#4  libwebkit2gtk-4.1.so.0 + 0x153de84
#5  libwebkit2gtk-4.1.so.0 + 0x1a49209
#6  libwebkit2gtk-4.1.so.0 + 0x1a4bce2
#7  libjavascriptcoregtk-4.1.so.0 + 0x22e591f
#8  libjavascriptcoregtk-4.1.so.0 + 0x22e5b9f
#9  libglib-2.0.so.0 + 0x6dbd5              (g_main_context_dispatch)
#11 g_main_context_iteration
#12 gtk_main_iteration_do
#13 gtk::auto::functions::main_iteration_do
#14 tauri_runtime_wry::make_event_handler::{closure#0}
#16 tao::platform_impl::platform::event_loop::EventLoop<T>::run_return
#19 <tauri_runtime_wry::Wry<T> as tauri_runtime::Runtime<T>>::run
#21 buzz_lib::run
#22 buzz_desktop::main

Two things that may or may not be meaningful — flagging them as observations, not conclusions:

• The JSC frames sit directly under g_main_context_dispatch, i.e. the fault is reached from a GSource callback rather than from an IPC/command path in Buzz's own code.
• SEGV_MAPERR in every one of the 10 dumps collected today, always on the first community switch.

Environment: Arch Linux (Wayland session, app run with GDK_BACKEND=x11 to match the AppImage), NVIDIA. debuginfod.archlinux.org has no debuginfo for webkit2gtk-4.1 within a reasonable fetch, so I could not resolve the WebKit frames further. If a maintainer can map those offsets against a 2.52.5 build with symbols, that should pin it down.

[rolznz]

--safe-rendering also does not work for me. Crashes both on .deb and AppImage versions.

[shawnyeager]

Another data point that rules out the GPU vendor: AMD, not NVIDIA, and still byte-identical stacks.

Environment: Arch Linux, Wayland (Hyprland), AMD Phoenix1 / amdgpu — no NVIDIA anywhere on this machine. Buzz 0.5.3 (newer than anything else in this thread), installed via the AUR buzz-bin package, which is a thin wrapper that just ar x-extracts the official Buzz_0.5.3_amd64.deb into a pacman package — so no AppImage, no bundled libs, linking against Arch's system webkit2gtk-4.1 2.52.5-2.

The offsets match @HolgerHatGarKeineNode's system-WebKitGTK trace exactly:

#0  0x00007fe39a8ec04e n/a (libwebkit2gtk-4.1.so.0 + 0x1cec04e)
#1  0x00007fe39a885a6a n/a (libwebkit2gtk-4.1.so.0 + 0x1c85a6a)
#2  0x00007fe39a0cf5f6 n/a (libwebkit2gtk-4.1.so.0 + 0x14cf5f6)
#3  0x00007fe39a656762 n/a (libwebkit2gtk-4.1.so.0 + 0x1a56762)
#4  0x00007fe39a13de84 n/a (libwebkit2gtk-4.1.so.0 + 0x153de84)
#5  0x00007fe39a649209 n/a (libwebkit2gtk-4.1.so.0 + 0x1a49209)
#6  0x00007fe39a64bce2 n/a (libwebkit2gtk-4.1.so.0 + 0x1a4bce2)
#7  0x00007fe3980e591f n/a (libjavascriptcoregtk-4.1.so.0 + 0x22e591f)
#8  0x00007fe3980e5b9f n/a (libjavascriptcoregtk-4.1.so.0 + 0x22e5b9f)
#9  0x00007fe39e607c76 n/a (libglib-2.0.so.0 + 0x61c76)
#10 0x00007fe39e609ed7 n/a (libglib-2.0.so.0 + 0x63ed7)
#11 0x00007fe39e60a055 g_main_context_iteration (libglib-2.0.so.0 + 0x64055)
#12 0x00007fe3985ead7f gtk_main_iteration_do (libgtk-3.so.0 + 0x1ead7f)
#13 0x00005647d210c837 n/a (buzz-desktop + 0x57da837)
#14 0x00005647cf5f0bc5 n/a (buzz-desktop + 0x2cbebc5)

SIGSEGV / SEGV_MAPERR in every dump, always on the UI thread. So the same fault reproduces across NVIDIA+X11 and AMD+Wayland, across AppImage / .deb / pacman-extracted-deb installs, and against both bundled and system WebKit builds.

WEBKIT_DISABLE_DMABUF_RENDERER=1 made no difference here either — the run crashed with the same offsets listed above. Worth noting what the app logged on startup with that variable set:

buzz-desktop: WebKit rendering left as-is — WEBKIT_DISABLE_DMABUF_RENDERER=1 set in the environment

That reads like Buzz deliberately ignores the bare environment variable, so on this machine it's only evidence that the env var alone is a no-op. I have not tested the --safe-rendering flag itself; others above report it doesn't help.

Frequency: 8 SIGSEGVs across two days — 5 on 0.5.2 (2026-07-30), 3 on 0.5.3 (2026-07-31), zero in the preceding two weeks on 0.5.0 and 0.5.1.

Caveat: I can't confirm these particular crashes followed a community switch — nobody was recording the UI action at the time, so I'm matching on the stack, not the repro steps. Given the original report here is on 0.5.0 and mine only start at 0.5.2, my quiet fortnight is more likely "wasn't switching communities" than "the bug wasn't there yet"; I'd treat any 0.5.2-regression theory with suspicion.

Happy to install the buzz-bin-debug package Arch's makepkg produces alongside the main one and re-symbolize, if a maintainer wants specific frames resolved.

[shawnyeager]

Symbolized: this is a null-pointer bug in WebKitGTK, and WEBKIT_DISABLE_DMABUF_RENDERER=1 is what causes it

@HolgerHatGarKeineNode asked for someone to map those offsets against a WebKitGTK 2.52.5 build with symbols. I was able to: debuginfod.archlinux.org does serve debuginfo for Arch's webkit2gtk-4.1 2.52.5-2 (build-id 27c28f21a1da90c012fd533f444ffb9dde0b933c, ~2.1 GB), and that is the exact library that produced the +0x1cec04e stacks in this thread. Full chain, from 12 of my own coredumps across Buzz 0.5.2 / 0.5.3 / 0.5.4 / 0.5.5:

#0  WebKit::AcceleratedBackingStore::update(LayerTreeContext const&)   AcceleratedBackingStore.cpp:754
#1  WebKit::DrawingAreaProxyCoordinatedGraphics::enterAcceleratedCompositingMode()
      └─ WebKit::WebPageProxy::enterAcceleratedCompositingMode()        WebPageProxy.cpp:12788
#2  WebKit::DrawingAreaProxy::didReceiveMessage()                       ← Messages::DrawingAreaProxy::EnterAcceleratedCompositingMode
#3  IPC::MessageReceiverMap::dispatchMessage()
#4  WebKit::WebProcessProxy::didReceiveMessage()
#5  IPC::Connection::dispatchMessage(UniqueRef<Decoder>)                Connection.cpp:1481
#6  IPC::Connection::dispatchIncomingMessages()                         Connection.cpp:1600
#7  WTF::RunLoop::performWork()                                         RunLoop.cpp:146
#8  WTF::RunLoop::$_3::__invoke()                                       RunLoopGLib.cpp:89

The crash

AcceleratedBackingStore.cpp:754 is the first line of update():

void AcceleratedBackingStore::update(const LayerTreeContext& context)
{
    if (m_surfaceID == context.contextID)   // ← line 754

m_surfaceID is at offset 72 (0x48) in AcceleratedBackingStore — confirmed against the DWARF, /* offset 72 | size 8 */ uint64_t m_surfaceID. Reading it through a null this faults at address 0x48, which is exactly the segfault at 48 that @craigderington and I both captured. this is null; the object was never created.

Why it is null

AcceleratedBackingStore::create() returns nullptr by design:

RefPtr<AcceleratedBackingStore> AcceleratedBackingStore::create(WebPageProxy& webPage)
{
    if (!HardwareAccelerationManager::singleton().canUseHardwareAcceleration() || !checkRequirements())
        return nullptr;
    ...
}

bool AcceleratedBackingStore::checkRequirements()
{
    if (!rendererBufferTransportMode().isEmpty())
        return gtkCanUseHardwareAcceleration();
    return false;
}

and rendererBufferTransportMode() bails out before adding any mode at all when the dmabuf renderer is switched off:

const char* disableDMABuf = getenv("WEBKIT_DISABLE_DMABUF_RENDERER");
if (disableDMABuf && g_strcmp0(disableDMABuf, "0"))
    return;                       // mode stays empty → checkRequirements() false → create() null

So with WEBKIT_DISABLE_DMABUF_RENDERER=1, priv->acceleratedBackingStore is null for the whole life of the widget. The app runs fine until something first requires compositing — and switching communities runs a view transition (runCommunityViewTransition), which does exactly that. The web process sends EnterAcceleratedCompositingMode, and the UI process dereferences null.

The WebKitGTK bug

WebKitWebViewBase.cpp guards that same pointer two different ways. These two check it:

void webkitWebViewBaseDidRelaunchWebProcess(WebKitWebViewBase* webkitWebViewBase)   // :2937
{
    if (priv->acceleratedBackingStore) { ... }

void webkitWebViewBasePageClosed(WebKitWebViewBase* webkitWebViewBase)              // :2953
{
    if (webkitWebViewBase->priv->acceleratedBackingStore)

These three do not — they use ASSERT(), which compiles to nothing in a release build:

void webkitWebViewBaseEnterAcceleratedCompositingMode(...)   // :2901
{
    ASSERT(webkitWebViewBase->priv->acceleratedBackingStore);
    webkitWebViewBase->priv->acceleratedBackingStore->update(layerTreeContext);
}
// same in webkitWebViewBaseUpdateAcceleratedCompositingMode (:2907)
// and webkitWebViewBaseExitAcceleratedCompositingMode (:2913)

A null backing store is a legitimate, documented state, so the assertion is simply the wrong guard. Patch (against webkitgtk-2.52.5) — replacing the assertions with the runtime check already used elsewhere in the same file:

 void webkitWebViewBaseEnterAcceleratedCompositingMode(WebKitWebViewBase* webkitWebViewBase, const LayerTreeContext& layerTreeContext)
 {
-    ASSERT(webkitWebViewBase->priv->acceleratedBackingStore);
-    webkitWebViewBase->priv->acceleratedBackingStore->update(layerTreeContext);
+    if (!webkitWebViewBase->priv->acceleratedBackingStore)
+        return;
+    webkitWebViewBase->priv->acceleratedBackingStore->update(layerTreeContext);
 }

(and the same in webkitWebViewBaseUpdateAcceleratedCompositingMode / webkitWebViewBaseExitAcceleratedCompositingMode).

This explains why the suggested workarounds made things worse

WEBKIT_DISABLE_DMABUF_RENDERER=1 is the leading recommendation in this thread and in #4142, and it is what Buzz itself applies via webkit_rendering.rs (added in #3271). It does not fail to fix this crash — it is one of the ways to cause it. Same for --safe-rendering, which sets that variable plus WEBKIT_DISABLE_COMPOSITING_MODE.

It also explains the reports of 100% reproducibility on AppImage. desktop/src-tauri/src/webkit_rendering.rs applies the variable automatically when it detects an NVIDIA GPU or an AppImage launch, so most people in this thread had a guaranteed-null backing store before they touched anything.

In my own case the variable came from my session rather than from Buzz (~/.config/environment.d/webkit.conf, set for an unrelated black-window issue on a Radeon 760M). I have zero buzz-desktop coredumps before I added that file and a steady stream after it, across four Buzz releases — which is also why my earlier note in this thread blamed 0.5.2. That was wrong; 0.5.2 happened to be the first launch after the variable went live.

Workaround

Set WEBKIT_DISABLE_DMABUF_RENDERER=0 rather than unsetting it. WebKit treats "0" as "not disabled", and Buzz's webkit_rendering.rs treats any assignment — including =0 — as the user taking over, so the NVIDIA/AppImage heuristic stands down instead of putting it back:

WEBKIT_DISABLE_DMABUF_RENDERER=0 ./Buzz_0.5.5_amd64.AppImage

If you originally set the variable to fix black windows or the #2338 startup abort, try WEBKIT_DMABUF_RENDERER_FORCE_SHM=1 instead. It selects the shared-memory buffer path — the thing disabling dmabuf was getting you — but it is applied after the emptiness check, so the transport mode stays non-empty and the backing store is still created.

What I have and have not verified

Verified: the symbolization, the 0x48 member offset against the DWARF, the source paths above at tag webkitgtk-2.52.5, and that WEBKIT_DISABLE_DMABUF_RENDERER=1 was present in the environment of my crashed processes (read back out of the coredumps, including the very first one). On this machine gtkCanUseHardwareAcceleration() returns true and both EGL_KHR_platform_gbm and EGL_MESA_platform_surfaceless are present, so the empty transport mode is the only failing gate.

Not verified: I have not rebuilt WebKitGTK with the patch, and I have not yet run a long session with the variable flipped to confirm the crash is gone — the causal chain is read from source, not yet demonstrated end-to-end. If someone on the AppImage build can try WEBKIT_DISABLE_DMABUF_RENDERER=0 and report back, that would confirm or kill this quickly.

The fix belongs in WebKitGTK, not Buzz. Buzz's side of it is a judgement call for maintainers: the webkit_rendering.rs heuristic trades the #2338 startup abort for this crash, and until WebKit is fixed there is no setting that avoids both on affected hardware.

[rolznz]

Unfortunately, neither WEBKIT_DISABLE_DMABUF_RENDERER=0 and WEBKIT_DISABLE_DMABUF_RENDERER=1 help for me.

$ WEBKIT_DISABLE_DMABUF_RENDERER=0 buzz-desktop 
buzz-desktop: WebKit rendering left as-is — WEBKIT_DISABLE_DMABUF_RENDERER=0 set in the environment
buzz-desktop: persisted identity pubkey xxx
buzz-desktop: media proxy listening on 127.0.0.1:45631
buzz-desktop: repos dir resolved at boot — REPOS symlinked to configured `xxx`
[0:28:29.064503570] [14500]  WARN IPAManager ipa_manager.cpp:154 No IPA found in '/usr/lib/x86_64-linux-gnu/libcamera'
[0:28:29.064546264] [14500]  INFO Camera camera_manager.cpp:284 libcamera v0.2.0

(WebKitWebProcess:14500): GStreamer-CRITICAL **: 10:46:20.193: gst_value_set_int_range_step: assertion 'start < end' failed

(WebKitWebProcess:14500): GStreamer-CRITICAL **: 10:46:20.193: gst_value_set_int_range_step: assertion 'start < end' failed
Killed

(Behavior is slightly different - it hangs and then shows the app not responding)

[oso0x34]

New evidence from another affected machine (Ubuntu 24.04, GNOME/X11, NVIDIA, WebKitGTK 2.52.3 system + bundled, Buzz AppImage — crash on every community switch, same segfault at 48 / offset fd69b2 as @craigderington's table):

The null backing store does not require WEBKIT_DISABLE_DMABUF_RENDERER.

We wrote a ~100-line repro outside Buzz — plain GTK + WebKitWebView whose page just calls document.startViewTransition() in a loop — and ran it with a scrubbed environment (env -i), one variable at a time:

Environment	Result
no WebKit vars at all	SIGSEGV, segfault at 48, offset fd69b2
WEBKIT_DMABUF_RENDERER_FORCE_SHM=1 (what Buzz auto-sets on NVIDIA/AppImage)	SIGSEGV, identical
WEBKIT_DISABLE_DMABUF_RENDERER=1	SIGSEGV, identical
ViewTransitions feature disabled via webkit_settings_set_feature_enabled()	clean run, page falls back

So @shawnyeager's mechanism (null AcceleratedBackingStore, ASSERT compiled out of release builds, first compositing demand dereferences it) is confirmed — but the empty-transport-via-env-var path is only one way in. On this X11 box the store is null by default, which explains why the #3654 FORCE_SHM heuristic didn't stop the reports here, and why every combination of rendering env vars in this thread failed: the environment can't fix it.

Worth noting that every affected report in this thread and in #4142 is X11 or XWayland (GDK_BACKEND=x11 is pinned by the AppImage), which fits "compositing unavailable on X11" being the common thread.

Two verified mitigations:

1. Engine side — disable the ViewTransitions WebKit feature. document.startViewTransition becomes undefined and Buzz's existing fallback in runCommunityViewTransition does an instant switch. I've been running this way via an LD_PRELOAD shim: community switching is 100% stable where it crashed 100% before.
2. App side — skip the view transition on Linux WebKitGTK: fix(desktop): skip community view transition on Linux WebKitGTK to avoid UI-process segfault #5768. Repro source and the full matrix are in that PR.

An upstream WebKitGTK report with the minimal repro is prepared — the proposed engine fix is exactly the ASSERT → runtime null-check that @shawnyeager identified. I'll link it here once it's filed.

[oso0x34]

Upstream report filed: https://bugs.webkit.org/show_bug.cgi?id=321683 (WebKit / WebKitGTK), with the minimal GTK repro attached and the proposed ASSERT → runtime-null-check patch for the three unguarded call sites in WebKitWebViewBase.cpp.

That's the engine-side fix. The app-side guard is #5768 if maintainers want the crash stopped before a fixed WebKitGTK reaches users' distros.

[HolgerHatGarKeineNode]

Confirmed fixed on the current release — community switching no longer crashes here (was a hard SIGSEGV before; tested on 0.5.14).

Checking the repo history, the fix is most likely #4505, shipped in 0.5.6 (60ae74b, 2026-08-07). Before it, Buzz's own Linux rendering heuristic (#3271) exported WEBKIT_DISABLE_DMABUF_RENDERER=1 on NVIDIA/AppImage launches — which is exactly the crash trigger @shawnyeager symbolized and @oso0x34 confirmed: on current WebKitGTK that variable empties the renderer buffer transport mode, AcceleratedBackingStore::create() returns null, and the first compositing demand — the community-switch view transition — dereferences it (segfault at 48).

#4505 switched the heuristic (and --safe-rendering) to WEBKIT_DMABUF_RENDERER_FORCE_SHM=1, which keeps the shared-memory transport in the set so the backing store is actually created, while preserving the #2338 black-window protection. The timeline fits: crash reports in this thread run through 0.5.5, and the fix landed in 0.5.6.

Two caveats before anyone closes this as fully resolved:

• Per @oso0x34's matrix, on configurations where the backing store is null regardless of env vars (their X11/GNOME/NVIDIA box), FORCE_SHM=1 does not prevent the crash. Those machines still need the upstream WebKitGTK fix (https://bugs.webkit.org/show_bug.cgi?id=321683 — still NEW, unassigned) and/or the app-side view-transition guard fix(desktop): skip community view transition on Linux WebKitGTK to avoid UI-process segfault #5768 (still open).
• A stale WEBKIT_DISABLE_DMABUF_RENDERER=1 exported in the session environment reintroduces the crash on current WebKitGTK. 0.5.6+ logs a startup warning about exactly that and points at FORCE_SHM instead.

So: fixed since 0.5.6 for machines that were hit via Buzz's own heuristic; the underlying WebKitGTK bug remains live upstream. If you still crash on ≥ 0.5.6, please comment with install type, GPU, session type (X11/Wayland), and whether WEBKIT_DISABLE_DMABUF_RENDERER is set in your environment — that would be the residual population.