Skip to content

WEBKIT_DISABLE_DMABUF_RENDERER crashes WebKitGTK on NVIDIA instead of falling back to shared memory #3654

New issue
New issue
Open
Open
WEBKIT_DISABLE_DMABUF_RENDERER crashes WebKitGTK on NVIDIA instead of falling back to shared memory#3654

Description

@kwsantiago
kwsantiago
opened on Jul 30, 2026

webkit_rendering.rs sets WEBKIT_DISABLE_DMABUF_RENDERER=1 on NVIDIA GPUs and on AppImage packaging to avoid the #2338 startup abort, with the stated intent of falling back to the shared-memory buffer path.

On current WebKitGTK that variable no longer falls back. It returns before mode.add(RendererBufferTransportMode::SharedMemory), so the transport mode is left empty, AcceleratedBackingStore::create() returns nullptr, and webkitWebViewBaseEnterAcceleratedCompositingMode() dereferences it, guarded only by an ASSERT, which is compiled out in release builds. The app SIGSEGVs the first time content needs a compositing layer. Switching workspaces does it every time.

#0 AcceleratedBackingStore::update()   AcceleratedBackingStore.cpp:808
#1 WebPageProxy::enterAcceleratedCompositingMode()
#2 DrawingAreaProxyCoordinatedGraphics::enterAcceleratedCompositingMode()
   <- IPC Messages::DrawingAreaProxy::EnterAcceleratedCompositingMode

Measured in the failing process: transport mode 0x00000000, create() returned 0x0, and priv->acceleratedBackingStore is NULL in the core dump. The webview is never disposed (breakpoint on webkitWebViewBaseDispose never fires), so the pointer is null from creation rather than from teardown.

WEBKIT_DMABUF_RENDERER_FORCE_SHM=1 returns after SharedMemory is added. That is the documented intent, no hardware dmabuf path, and it leaves the backing store valid.

Verification

Ubuntu 24.04, WebKitGTK 2.52.3, GeForce RTX 3050 Ti (driver 580.173.02), X11.

build module log line workspace switch
0.4.24 AppImage (ships DISABLE_DMABUF) WEBKIT_DISABLE_DMABUF_RENDERER=1 — NVIDIA GPU, AppImage SIGSEGV
main with HEURISTIC = [FORCE_SHM] WEBKIT_DMABUF_RENDERER_FORCE_SHM=1 — NVIDIA GPU works

Same result running the AppImage with the two variables set by hand, so the variable is the only difference and not the build.

Both runs pin EGL to Mesa (__EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json). Debian and Ubuntu ship disable-nvidia-dmabuf.patch in webkit2gtk, which empties the same transport mode on NVIDIA regardless of this variable; without the pin that patch masks the difference. It also means this change alone will not fix Debian/Ubuntu users. I am reporting that to Debian separately.

Not verified

Whether FORCE_SHM still avoids the #2338 abort. I do not have hardware that reproduces #2338, and that is the reason the setting exists, so it is worth confirming before changing it.

If the swap looks right I am happy to send the PR. The module's unit tests pin the current variable, so they would need updating too, and OWNED would need a decision: adding FORCE_SHM keeps the "everything this module may set" invariant, but changes which user assignments make it stand down.

Activity

  1. orestes74 commented on Aug 3, 2026

    @orestes74
    orestes74
    on Aug 3, 2026

    Confirming this on DGX Spark (Ubuntu 24.04 ARM64, NVIDIA GPU 10de:2e12, WebKitGTK 2.52.3, X11), Buzz v0.5.2→v0.5.3 built from source.

    Symptoms matched exactly: just production completes successfully, Vite/buzz-desktop/WebKitWebProcess all running, but the window renders transparent/blank, or only the first frame of the splash screen shows before rendering freezes.

    FORCE_SHM alone wasn't enough for me — I had to explicitly override the NVIDIA heuristic:

    bash
    WEBKIT_DISABLE_DMABUF_RENDERER=0
    WEBKIT_DMABUF_RENDERER_FORCE_SHM=1
    just production

    Without WEBKIT_DISABLE_DMABUF_RENDERER=0, the app's own NVIDIA detection in webkit_rendering.rs re-sets DISABLE_DMABUF_RENDERER=1 and FORCE_SHM alone doesn't override it.

    Also noticed: adding a temporary webview.open_devtools() call in .on_webview_ready() (guarded by #[cfg(debug_assertions)]) forced a repaint that made the content render correctly — and it stayed rendered correctly even after closing devtools. Didn't fully confirm the mechanism, but it looks like devtools forces a resize/expose event that gets WebKit's compositor to retry creating the backing store, which succeeds once FORCE_SHM is already in effect.

    Things that did not help in my case: WEBKIT_DISABLE_COMPOSITING_MODE=1 alone, WEBKIT_SKIA_ENABLE_CPU_RENDERING=1 alone, GDK_BACKEND=x11, forcing Mesa EGL (got failed to create dri2 screen / driver (null)), full reinstall, clearing WebKit/Tauri caches.

    Happy to test a PR if one gets opened for this.

  2. chessing234 commented on Aug 3, 2026

    @chessing234
    chessing234
    on Aug 3, 2026
    Contributor

    opened #4505 — switches the heuristic to FORCE_SHM and updates the linux troubleshooting docs.

  3. wpfleger96
    added 2 commits that reference this issue on Aug 7, 2026

    docs(linux): scope FORCE_SHM claims to paths without the distro NVIDI…

    cdd0805

    fix(desktop): use WEBKIT_DMABUF_RENDERER_FORCE_SHM for NVIDIA/AppImage (

    60ae74b
  4. atishpatel
    added a commit that references this issue on Aug 7, 2026

    Merge remote-tracking branch 'origin/main' into benchmark/flush-usage…

    c7e3409
  5. wpfleger96
    added a commit that references this issue on Aug 7, 2026

    Merge remote-tracking branch 'origin/main' into duncan/permission-policy

    fe901d8
  6. 41fred
    added a commit that references this issue on Aug 9, 2026

    fix(desktop): use WEBKIT_DMABUF_RENDERER_FORCE_SHM for NVIDIA/AppImage (

    1c0b551
  7. wpfleger96
    added a commit that references this issue on Aug 10, 2026

    Merge remote-tracking branch 'origin/main' into duncan/claude-config-…

    74b9173
  8. bhargavms
    added a commit that references this issue on Aug 18, 2026

    fix(desktop): use WEBKIT_DMABUF_RENDERER_FORCE_SHM for NVIDIA/AppImage (

    b266ce8
  9. kaalph
    added 3 commits that reference this issue on Aug 21, 2026

    Merge remote-tracking branch 'origin/main' into benchmark/flush-usage…

    06bf2c9

    Merge remote-tracking branch 'origin/main' into duncan/permission-policy

    fa30c47

    Merge remote-tracking branch 'origin/main' into duncan/claude-config-…

    63cf038
  10. BradGroux
    added a commit that references this issue on Aug 23, 2026

    fix(desktop): use WEBKIT_DMABUF_RENDERER_FORCE_SHM for NVIDIA/AppImage (

    a64f4c8
  11. danielhanchen
    added 2 commits that reference this issue on Aug 24, 2026

    Pick the renderer workaround per failure mode and restore the operato…

    aec95dc

    desktop: disable the webkitgtk dmabuf renderer on nvidia, not only on…

    ce0fa66

  12. kcaashish commented on Sep 21, 2026

    @kcaashish
    kcaashish
    on Sep 21, 2026

    Independent confirmation from another WebKitGTK app (Radar — Wails v2 + GTK3), plus one result that widens the scope of this issue: neither NVIDIA nor a workspace switch is required.

    Reproduced on a pure software stack — Docker, Ubuntu 25.10, WebKitGTK 2.52.3 (libwebkit2gtk-4.1.so.0.21.7), Xvfb + llvmpipe, no GPU and no NVIDIA driver present, so disable-nvidia-dmabuf.patch's isNVIDIA() returns false on its own and nothing masks the variable. Same fault site you measured:

    #0  AcceleratedBackingStore::update()            AcceleratedBackingStore.cpp:808
#1  WebPageProxy::enterAcceleratedCompositingMode()        WebPageProxy.cpp:12724
#2  DrawingAreaProxyCoordinatedGraphics::enterAcceleratedCompositingMode()
#4  IPC didReceiveMessage

    It also reproduces in WebKitGTK's own MiniBrowser — no app framework, no bindings, the stack bottoms out at Tools/MiniBrowser/gtk/main.c — from a 20-line page whose only action is document.startViewTransition():

    env MiniBrowser + one startViewTransition()
    (none) alive
    WEBKIT_DISABLE_DMABUF_RENDERER=1 SIGSEGV
    WEBKIT_DMABUF_RENDERER_FORCE_SHM=1 alive

    The trigger is narrow: translateZ(0)/will-change, a running CSS transform animation, backdrop-filter, a 2D canvas and a WebGL context were each fired first and all survive. Only startViewTransition() faults — it appears to force accelerated compositing entry rather than request it, so it's the one path that ignores the UI process having decided hardware acceleration is unavailable. The hardware-acceleration policy is not a lever either: ON_DEMAND, ALWAYS and NEVER all crash identically.

    Two things that may be useful here:

    • Your title scopes this to NVIDIA, but the variable is sufficient on its own. The FORCE_SHM swap in fix(desktop): use WEBKIT_DMABUF_RENDERER_FORCE_SHM for NVIDIA/AppImage (#3654) #4505 therefore helps any user whose transport set is emptied by WEBKIT_DISABLE_DMABUF_RENDERER, not only the NVIDIA ones — which I think strengthens the case for it. (It still won't reach a patched-NVIDIA host, where isNVIDIA() returns before the same mode.add and FORCE_SHM is never read, exactly as you noted.)
    • Since MiniBrowser reproduces it, I've filed it upstream: https://bugs.webkit.org/show_bug.cgi?id=324730, asking for both halves — restoring the variable's documented meaning (skip only the Hardware addition, still mode.add(SharedMemory)), and a null check in the AC-entry path, which is the only thing that helps when the set is emptied by something other than this variable. Your core-dump measurements are cited there; shout if you'd like anything corrected or added.

    The reproduction harness is attached to that bug (test case, symbolized backtrace, and a one-command Docker setup that needs no GPU) if a hermetic regression fixture is useful to you.

  13. abipalli
    added a commit that references this issue on Oct 7, 2026

    fix(desktop): use WEBKIT_DMABUF_RENDERER_FORCE_SHM for NVIDIA/AppImage (

    1c82198
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions