Linux desktop: WebKitWebProcess segfaults in PipeWire's module-metadata on startup (device enumeration, no huddle join needed)

[MK-xOne]

Environment

• Arch Linux, KDE Plasma / Wayland
• Buzz 0.5.3 (Buzz_0.5.3_amd64.AppImage, extracted AppDir install)
• pipewire 1.6.7, gst-plugins-bad/good 1.28.5, webkit2gtk-4.1 (bundled)

Symptom

Shortly after launching Buzz (roughly 40-60s in, no huddle join required), WebKitWebProcess segfaults and the whole renderer dies. The main buzz-desktop process and WebKitNetworkProcess stay alive with no renderer to draw the window, so from the user's side it looks like a freeze rather than a crash — no dialog, just a dead window.

Reproduced 3 times with an identical fault signature (2 historical + 1 fresh repro today), and this specific top-of-stack shape (pipewire/protocol-native) appears in all 19 WebKitWebProcess coredumps logged since 2026-07-17.

Not the known #3494 issue

This is not the bundled libsoup/libnghttp2 AppImage-shadowing bug (#3494) — that workaround (renaming the bundled libs, clearing the GStreamer registry cache) is applied here and does not prevent this crash.

Symbolized backtrace

Via coredumpctl debug <pid> --debugger=gdb -A "-batch -ex 'thread apply all bt' -ex quit" with Arch's debuginfod:

Main WebProcess thread — blocked waiting on device enumeration, called directly from WebKit:

Thread N (main thread):
#0  ... pthread_cond_wait () from libc.so.6
#1  ... from /usr/lib/spa-0.2/support/libspa-support.so
#2  ... from /usr/lib/gstreamer-1.0/libgstpipewire.so
#3  gst_device_provider_start () from libgstreamer-1.0.so.0
#4  ... from libwebkit2gtk-4.1.so.0

The PipeWire client's own main-loop thread — this is the one that actually dies:

#0  0x0000000000000003 in ?? ()
#1  ... from /usr/lib/pipewire-0.3/libpipewire-module-metadata.so
#2  ... from /usr/lib/pipewire-0.3/libpipewire-module-protocol-native.so
#3  ... from /usr/lib/pipewire-0.3/libpipewire-module-protocol-native.so
#4  ... from /usr/lib/spa-0.2/support/libspa-support.so
#5  ... from libpipewire-0.3.so.0

Frame #0 is a call through literal address 0x3 — a corrupted/uninitialized callback pointer, not a normal bad-pointer bug. Every neighboring frame resolved cleanly via debuginfod, so this isn't a missing-symbols artifact — it's a genuine wild jump.

Kernel log corroborates on two occurrences:

segfault at 3 ip 0000000000000003 ... error 14
Code: Unable to access opcode bytes at 0xffffffffffffffd9.

What this looks like

WebKit's media-device enumeration (gst_device_provider_start(), presumably triggered automatically by a camera/mic-capable UI element on load rather than requiring an explicit huddle join) opens a PipeWire client connection. On that client's own main-loop thread, something invokes a metadata-change callback (libpipewire-module-metadata.so) through a garbage function pointer, killing the process. GST_DEBUG=3 shows nothing before the crash — it happens entirely inside PipeWire's client code, below GStreamer's own error/message reporting, which is presumably why this hasn't surfaced as a catchable GStreamer error anywhere.

Reproduction

1. Launch the 0.5.3 AppImage (extracted) on Arch with pipewire 1.6.7.
2. Wait ~40-60s without interacting with any huddle/call UI.
3. WebKitWebProcess segfaults; buzz-desktop and WebKitNetworkProcess remain running with a dead window.

Happy to provide the full symbolized backtrace/coredump or test further if useful — this looked like it might also be worth a pipewire/gst-plugins report, but I don't have an account there to check for an existing issue.

[iroiro147]

Thanks for the exceptionally thorough diagnosis — symbolized backtraces, kernel-log corroboration, and the explicit #3494 exclusion make this far easier to triage than the average renderer-crash report.

Parsing the evidence, this points squarely upstream of Buzz:

1. The fault is entirely inside PipeWire's client modules. The dying thread is PipeWire's own main-loop thread, jumping through literal address 0x3 — a garbage/uninitialized callback pointer inside libpipewire-module-metadata.so → libpipewire-module-protocol-native.so. Nothing on that stack is Buzz, WebKit, or GStreamer code; they only opened the client connection.

2. Buzz doesn't touch PipeWire directly. The call chain is WebKit (gst_device_provider_start) → GStreamer's pipewire plugin → PipeWire client libs. The trigger is WebKit's automatic media-device enumeration on a camera/mic-capable page load, which the desktop shell does regardless of huddle state. That's why no huddle join is required — the crash is in device discovery, not media capture.

3. 0x3 as a jump target + error 14 (noexec page-not-present) reads as a wild function-pointer call, not a normal bad-pointer deref — consistent with a use-after-free or an unregistered/removed metadata callback firing, i.e. a PipeWire (or pipewire↔spa version-skew) defect rather than an application bug.

So this is worth filing upstream against PipeWire (and worth checking for pipewire/spa version mismatch on the system: a libspa-support.so / libpipewire-module-* built against a different point release than the running daemon is a classic cause of exactly this kind of callback desync on rolling distros like Arch). The coredump backtrace + coredumpctl metadata is precisely what the PipeWire tracker wants.

On the Buzz side, the genuinely actionable (and separable) follow-up isn't preventing the crash but survivability: right now a WebKitWebProcess death presents as a silent "dead window" freeze, because the main buzz-desktop and WebKitNetworkProcess stay alive with no renderer. WebKitGTK exposes a web-process-terminated signal on WebKitWebView; handling it on the desktop surface (log it, and either reload the view or surface a "renderer crashed — click to restart" state instead of a frozen window) would turn this whole class of real-world upstream renderer crashes from a mysterious hang into a recoverable, diagnosable event.

Happy to open a dedicated, narrowly-scoped issue for the web-process-terminated handling if that's desired — that's a real Buzz-code fix independent of whatever PipeWire does. The segfault root-cause itself looks like it belongs to PipeWire.