[bug] Linux: blank window — WebKitWebProcess SIGABRT on webkit2gtk 2.52.3; still blank on .2 with WebProcess alive

[jramiresbrito]

Summary

Buzz Desktop opens a window that never renders any UI on Ubuntu 26.04 (Wayland, Intel iGPU). The Rust backend runs fine: identity persists, the media proxy binds, the repos dir resolves, and buzz-acp connects to the relay, discovers channels, and reports presence set to online. The webview alone fails. Buzz logs nothing about it, so the app appears to start cleanly.

WebKitWebProcess aborts itself seconds after exec. I confirmed that with strace and an apport core dump. Downgrading WebKit one revision stops the abort and the window stays blank, so two separate problems exist.

Environment

Buzz	0.5.14 and 0.5.17 (.deb from GitHub releases)
OS	Ubuntu 26.04 LTS (resolute), upgraded in place from 22.04
Kernel	7.0.0-29-generic
Session	Wayland, GNOME Shell 50.1
GPU	Intel Alder Lake-P GT2 [Iris Xe] 8086:46a6, i7-1260P (no NVIDIA)
WebKitGTK	libwebkit2gtk-4.1-0 2.52.3-0ubuntu0.26.04.3, also tested .2
libsoup3	3.6.6-1
GStreamer	1.28.2-1
GLib	2.88.0-1
GTK3	3.24.52-0ubuntu1

Two failure modes

WebKitGTK	WebKitWebProcess	UI
2.52.3-0ubuntu0.26.04.3	execs, spawns ~20 threads, then SIGABRT (core dumped)	blank
2.52.3-0ubuntu0.26.04.2	survives, 50 threads, holds ~12% CPU	blank

Evidence

I ran strace -f -e trace=execve,clone,clone3 on a blank launch. WebKit does launch the web process, so nothing fails at spawn time:

<pid> execve("/usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/WebKitWebProcess",
             [".../WebKitWebProcess", "4", "35"], 0x... /* 100 vars */) = 0
<pid> clone3(...) x ~20 threads
<pid> --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=<same pid>, si_uid=1000} ---
<pid> +++ killed by SIGABRT (core dumped) +++

si_code=SI_TKILL with si_pid matching its own pid means the process called abort() on itself.
No external kill, no OOM.

The apport report (/var/crash/..._WebKitWebProcess.1001.crash) records:

ProblemType: Crash
Signal: 6
ExecutablePath: /usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/WebKitWebProcess
Package: libwebkit2gtk-4.1-0 2.52.3-0ubuntu0.26.04.3
ProcCmdline: /usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/WebKitWebProcess 4 35
StacktraceTop:
 pthread_kill () from /usr/lib/x86_64-linux-gnu/libc.so.6
 raise () from /usr/lib/x86_64-linux-gnu/libc.so.6
 abort () from /usr/lib/x86_64-linux-gnu/libc.so.6
 ?? () from /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.1.so.0
 ?? () from /usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.1.so.0

apport captured no AssertionMessage, and no assertion text appears anywhere in the report. That fits a RELEASE_ASSERT or CRASH() in a release build.

Ubuntu 26.04 gives no way to symbolize this. libwebkit2gtk-4.1-0-dbgsym exists on ddebs for ...26.04.2 and returns 404 for ...26.04.3. The archive holds no newer WebKit either: I probed .4, 2.52.4, 2.52.5 and 2.54.0, all 404.

A blank launch logs the lines below. A launch that rendered logs the same lines in the same order:

buzz-desktop: WebKit rendering left as-is — no NVIDIA GPU and not an AppImage
buzz-mesh: installed tokio runtime with 8 MiB worker stacks
buzz-desktop: team-membership-repair: repaired N record(s)
buzz-desktop: persisted identity pubkey <redacted>
buzz-desktop: media proxy listening on 127.0.0.1:<port>
buzz-desktop: repos dir resolved at boot — REPOS symlinked to configured <redacted>
buzz-mesh: status report after startup failed: relay unreachable: could not connect to relay

buzz-acp connects one second later, so that relay unreachable line misleads.

Leads

unsetenv() runs after thread creation. With G_MESSAGES_DEBUG=all, GLib flags two calls on every launch, both after the tokio runtime starts:

buzz-mesh: installed tokio runtime with 8 MiB worker stacks
(buzz-desktop:PID): GLib-DEBUG: unsetenv() is not thread-safe and should not be used after threads are created
(buzz-desktop:PID): GLib-DEBUG: unsetenv() is not thread-safe and should not be used after threads are created

unsetenv() after threads exist can corrupt environ, and WebKit copies environ into each auxiliary process it forks (see /* 100 vars */ above). Launches that rendered show the same warning, so I cannot tie it to the symptom. It stands as a thread-safety bug on its own. I suspect the code that strips reserved env keys, or the code that manages WEBKIT_DMABUF_RENDERER_FORCE_SHM.

WebKitGPUProcess never starts. A full strace contains two WebKit execs, WebKitNetworkProcess and WebKitWebProcess. On WebKitGTK 2.52 the GPU process composites content, so its absence could explain a live webview that paints nothing.

The surviving web process holds ~12% CPU on WebKit .2 instead of idling. The 0.5.17 entry fix(desktop): eliminate mounted-view CPU burn may relate, though 0.5.17 fails as well.

Ruled out, with evidence

• WEBKIT_DMABUF_RENDERER_FORCE_SHM=1 causes a blank window on 2.52.3. It helped on an earlier WebKit build, then inverted after an Ubuntu WebKit update. I removed it.
• --safe-rendering also gives a blank window. It refuses to start while FORCE_SHM is set, so testing the flag requires unsetting the variable first.
• WebKitGTK works on this machine. /usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/MiniBrowser about:blank spawns its WebKitWebProcess and renders on every attempt, same library, same session.
• The WebKit sandbox works. Zero AppArmor denials for buzz, webkit or bwrap, with kernel.apparmor_restrict_unprivileged_userns=1 set. glycin uses bwrap in the same process.
• systemd app-scope limits are not involved: MemoryMax=infinity, MemoryHigh=infinity, TasksMax=37305, no OOM events. Launching detached via setsid, outside any app scope, fails the same way.
• No resource pressure: 21 GB of 30 GB available, swap at 0 B, PSI memory pressure 0.00 (3 µs total for the whole boot), zero OOM kills.
• /dev/shm sits at 3% of 16 GB. The process holds 62 file descriptors against a 524288 limit.
• libsoup3 is 3.6.6, past the 3.4 floor, so the GitButler #12885 mismatch pattern does not apply.
• One leftover ~ubuntu24.04 GStreamer plugin exists (gstreamer1.0-icamera), and gst-inspect-1.0 icamerasrc loads it against GStreamer 1.28.2 with exit 0.
• WebKit installed matches candidate. apt update && apt upgrade changes nothing.
• The relay answers HTTP 200, and buzz-acp connects, subscribes and goes online.
• A second instance launched while another shuts down produces a guaranteed blank window, with a truncated log that stops after the rendering line and the tokio line. I excluded that case by confirming no other process was alive before each run above.

Reproduction

1. Ubuntu 26.04, Wayland, Intel iGPU, libwebkit2gtk-4.1-0 2.52.3-0ubuntu0.26.04.3.
2. Install the Buzz 0.5.17 .deb and launch it, from the dock icon or a shell.
3. The window opens and draws its decorations. The content area stays empty.
4. ps -C WebKitWebProcess returns nothing, and /var/crash/ gains a SIGABRT report.

On 0.5.14 the UI rendered on some launches, which pointed at a race. I measured those hit rates using a live WebKitWebProcess as a proxy for a rendered UI, and that proxy fails: on WebKit .2 the process lives while the window stays blank. Discount any frequency I quote. Only visual confirmation counts.

Questions

• Does Buzz expect WebKitGPUProcess to start on WebKitGTK 2.52? Its absence looks significant.
• Can the unsetenv() calls move ahead of tokio runtime startup, or use an approach that leaves
  environ alone?
• Could Buzz log WebKitWebView::web-process-terminated? A dead webview currently produces silence,
  which cost me two days of bisecting the wrong layers.

I can run more diagnostics. I hold strace traces, 18 labelled launch logs, and a failure that reproduces on every launch of 0.5.17.

[jramiresbrito]

Update: XWayland and 0.5.14 both fail

Three findings since I filed this.

XWayland behaves the same. GDK_BACKEND=x11 buzz-desktop draws the window decorations and leaves the content area a flat dark rectangle. The Wayland and DMABUF rendering path does not explain the failure.

No version renders reliably. 0.5.14 failed 12 consecutive launches on the same machine that rendered it earlier the same afternoon, with matching package versions and no env vars set. My original report implied 0.5.14 works some of the time. That does not hold up, so please treat 0.5.14 as no better than 0.5.17.

The same abort reproduces on 0.5.14, so this is not specific to 0.5.17:

Date: Wed Aug 19 15:46:57 2026
Signal: 6
Package: libwebkit2gtk-4.1-0 2.52.3-0ubuntu0.26.04.3
ProcCmdline: /usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/WebKitWebProcess 4 39
StacktraceTop:
 pthread_kill () / raise () / abort () / ?? () from libwebkit2gtk-4.1.so.0

Current state: Buzz 0.5.14, libwebkit2gtk-4.1-0 2.52.3-0ubuntu0.26.04.3, Wayland, no rendering env vars. Blank on every launch.

One correction to my own method, since it affects how much weight the numbers deserve. I counted "rendered" by checking for a live WebKitWebProcess. That check misleads: on WebKit ...26.04.2 the process runs at 440 to 500 MB while the window shows nothing. Only the two launches I confirmed by eye count as renders.

I have not tried the 0.5.17 AppImage. Tell me if that would narrow things, or name anything else you want instrumented and I will run it.

[jramiresbrito]

Update: the failure is intermittent, and my earlier version/WebKit boundaries were wrong

I spent a day bisecting this and want to correct the record before anyone follows my leads.

Buzz renders on a random subset of launches. Same machine, same packages, same displays, nothing
changed between attempts. Counts from today: 1 success in 4 attempts, 1 in 6, 1 in 12, and one run of
18 consecutive failures. A retry loop that relaunches until the web process appears is the only thing
that reliably gets a window.

Once it renders, it stays stable. The instance survives being moved to a second monitor with
Super+Shift+Arrow and keeps working indefinitely. Every failure I recorded happened at launch, or
once when dragging the window between outputs with the mouse.

When it fails, WebKitWebProcess aborts itself. This part is measured, not inferred:

<pid> execve(".../WebKitWebProcess", [..., "4", "35"], /* 100 vars */) = 0
<pid> clone3(...) x ~20 threads
<pid> --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=<same pid>, si_uid=1000} ---
<pid> +++ killed by SIGABRT (core dumped) +++

apport agrees: Signal: 6, abort() inside libwebkit2gtk-4.1.so.0, no AssertionMessage, which
fits a RELEASE_ASSERT in a release build. WebKitGPUProcess never execs on any launch, successful
or not.

Retractions

Each of these looked like a fix, then failed on a later attempt. None of them changes the odds:

• Buzz version. 0.5.14 rendered a few times, then failed 12 straight. 0.5.17 failed 18 straight,
  then rendered on attempt 4 after a reboot. My earlier claim of a 0.5.14 to 0.5.17 regression does
  not hold.
• WebKitGTK version. Downgrading libwebkit2gtk-4.1-0 from 2.52.3-0ubuntu0.26.04.3 to .2
  stops the abort (the web process survives at 440 to 500 MB) and the window is still blank. So the
  abort is not the only failure mode, and .3 is not a boundary.
• The dock. Unplugging the Thunderbolt dock appeared to fix it twice, then produced a blank window
  with the dock unplugged.
• Display count and scale. Fails with one display and with two. Internal panel runs 3840x2400 at
  250% scale, external 1920x1080 at 100%. GDK_SCALE=1 changes nothing, and under Wayland fractional
  scaling that variable is ignored anyway.
• Wayland vs XWayland. GDK_BACKEND=x11 is blank too.
• prefers-reduced-motion. Setting org.gnome.desktop.interface enable-animations false produced
  a working window immediately after 18 failures, which pointed at the compositor-accelerated shimmer
  in fix(desktop): eliminate mounted-view CPU burn — compositor-safe shimmer, observer append fast path, poll-tick disk reads #6198. Later launches with the same setting were blank. Treat this as unexplained rather than as
  a fix, though fix(desktop): eliminate mounted-view CPU burn — compositor-safe shimmer, observer append fast path, poll-tick disk reads #6198 is still worth a look given it moved an animation onto the compositor.

Still ruled out with evidence

WebKitGTK itself works: /usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/MiniBrowser about:blank spawns its
web process and renders on every attempt on this machine. Also excluded: the WebKit sandbox and user
namespaces (zero AppArmor denials), systemd app-scope limits, memory and CPU pressure (21 GB free, PSI
0.00, no OOM), /dev/shm, file descriptors, libsoup3 version, GStreamer plugin ABI, and relay
connectivity.

Environment

Ubuntu 26.04 (upgraded in place from 22.04), kernel 7.0.0-29-generic, Wayland, GNOME Shell 50.1,
Intel Alder Lake-P GT2 [Iris Xe] 8086:46a6, i7-1260P, no NVIDIA. libwebkit2gtk-4.1-0
2.52.3-0ubuntu0.26.04.3, libsoup3 3.6.6, GStreamer 1.28.2, GLib 2.88.0, GTK3 3.24.52. Buzz .deb.

Two notes for anyone reproducing

Ubuntu ships no libwebkit2gtk-4.1-0-dbgsym for ...26.04.3 (404 on ddebs, present for .2), so the
assertion cannot be symbolized on this distro, and there is no newer WebKit in the archive.

apport keeps one .crash per executable and silently drops later crashes, so delete
/var/crash/*WebKitWebProcess* between attempts or you will think nothing crashed.

Ask

Given it is intermittent and the web process dies silently, could Buzz log
WebKitWebView::web-process-terminated? That alone would have saved most of a day. Beyond that, tell
me what to instrument and I will run it, including a debug build if you have one.