[Bug][Linux] Window freezes: WebKitWebProcess dies with SIGILL (AVX vmovaps in JavaScriptCore) on CPUs without AVX

[JosefJezek]

Describe the bug

On Linux, the Buzz window freezes and stops responding to input a few seconds to a couple of minutes after launch. The window stays on screen and buzz-desktop keeps running, so it looks like a hang — but the WebKitGTK renderer has actually died.

Root cause is a SIGILL in JavaScriptCore: the crashing instruction is a VEX-encoded (AVX) vmovaps, and this CPU has no AVX. Intel disables AVX on Pentium Gold / Celeron parts, so any such machine hits this.

kernel: traps: WebKitWebProces[255352] trap invalid opcode
        ip:72354964e52c in libjavascriptcoregtk-4.1.so.0.10.11[24e52c,723549566000+1856000]
buzz-desktop[255315]: [pageProxyID=6, webPageID=7, PID=255352] WebPageProxy::dispatchProcessDidTerminate: reason=Crash
WebKitNetworkProcess[255332]: [webProcessIdentifier=4] NetworkConnectionToWebProcess::didClose: WebProcess closed its connection.

Disassembling that offset in the distro library:

$ objdump -d --start-address=0x24e500 --stop-address=0x24e540 \
    /lib/x86_64-linux-gnu/libjavascriptcoregtk-4.1.so.0.10.11
  24e52c:  c5 f8 29 84 24 b0 00 00 00   vmovaps %xmm0,0xb0(%rsp)

The site sits immediately before JSC::MacroAssemblerX86_64::collectCPUFeatures() — a JIT support/probe trampoline that saves GPRs and then the xmm registers with an AVX move that is not gated behind a CPU-feature check.

CPU flags on the affected machine (no avx):

model name : Intel(R) Pentium(R) Gold G6400 CPU @ 4.00GHz
flags      : ... sse4_2 xsave xsaveopt xsavec xsaves ...

Steps to reproduce

1. On an x86-64 CPU without AVX (e.g. Intel Pentium Gold G6400), install the Buzz .deb.
2. Launch buzz-desktop.
3. Within roughly 30 seconds the window stops repainting and no longer reacts to clicks or keyboard.
4. pgrep -af WebKitWebProcess shows no renderer, while buzz-desktop is still alive.
5. journalctl --since '-5min' | grep -E 'invalid opcode|dispatchProcessDidTerminate' shows the trace above.

Reproduced on every launch (3/3), including a crash recorded by apport before any debugging (/var/crash/_usr_lib_x86_64-linux-gnu_webkit2gtk-4.1_WebKitWebProcess.1000.crash, SignalName: SIGILL, Signal: 4).

Expected behavior

The app stays usable on CPUs without AVX. At minimum, a dead renderer should be detected and reported to the user (or the web view reloaded) instead of leaving a frozen window with no indication of what happened.

Version and platform

• Buzz version: 0.5.2 (.deb, dpkg -l buzz → 0.5.2 amd64)
• OS: Ubuntu 24.04, kernel 7.0.0-28-generic, Wayland session
• WebKit: libwebkit2gtk-4.1-0 2.52.3-0ubuntu0.24.04.1
• CPU: Intel Pentium Gold G6400 (Comet Lake, no AVX)

Logs / additional context

Workaround that fixes it completely — force the JavaScriptCore interpreter:

JSC_useJIT=0 buzz-desktop

With JSC_useJIT=0 the renderer stays alive and the UI remains responsive indefinitely (verified over several minutes of normal use); without it the renderer dies within ~30 s. Made permanent via a ~/.local/share/applications/Buzz.desktop override with Exec=env JSC_useJIT=0 buzz-desktop %u.

Two suggestions for Buzz itself, independent of the upstream WebKit bug:

1. Handle renderer termination — Tauri exposes the WebPageProxy terminate as a webview crash; showing an error or reloading beats a silently frozen window.
2. Consider setting JSC_useJIT=0 (or gating on /proc/cpuinfo lacking avx) in the Linux launcher until webkit2gtk ships a fix, since on affected CPUs the app is 100% unusable otherwise.

Also worth noting: the systemd .desktop entry declares MimeType=x-scheme-handler/buzz but its Exec=buzz-desktop has no %u, so buzz:// URLs are not passed to the app.

Likely also the underlying cause of the class of reports where the Linux window "just freezes"; distinct from #2982, which is a Skia/COLRv1 font-rendering abort.

[JosefJezek]

Update: this is a known upstream WebKitGTK regression, and it is already fixed upstream — but not in the 2.52.x stable series that current distros ship.

Upstream fix: 306002@main (e9b6a4f06, 2026-01-22), webkit.org/b/306004 — "[JSC] Use movaps instead of vmovaps in probe trampoline on non-AVX x86_64":

304684@main changed to unify the SIMD and non-SIMD probe trampolines into a single trampoline that always uses vmovaps to save/restore the full 128-bit XMM registers. This is correct on macOS where all x86_64 CPUs support AVX, but breaks on Linux and Windows where pre-AVX x86_64 CPUs still exist. On these CPUs, executing vmovaps causes SIGILL.

The fix splits it into ctiMasmProbeTrampoline (SSE movaps) and ctiMasmProbeTrampolineAVX (vmovaps), selected in MacroAssembler::probe() via supportsAVX(). That matches the disassembly in the report above exactly.

Affected versions (checked Source/JavaScriptCore/assembler/MacroAssemblerX86_64.cpp at each tag for ctiMasmProbeTrampolineAVX):

WebKitGTK	fixed?
2.48.5, 2.50.4	not affected (pre-regression split trampoline)
2.51.4, 2.52.0	affected (regression 304684@main landed)
2.52.3, 2.52.4, 2.52.5	affected — fix not backported to the 2.52 branch
2.53.1 … 2.53.4 (dev)	fixed

So the regression shipped with stable 2.52 and the fix currently only exists in the 2.53.x development series, i.e. it will reach users with stable 2.54.0. e9b6a4f06 is not an ancestor of any webkitgtk-2.52.x tag and no equivalent cherry-pick is present in 2.52.5 sources.

Practical impact for Buzz: on Ubuntu 24.04 the only available package is 2.52.3-0ubuntu0.24.04.1, so users on AVX-less CPUs cannot fix this by updating — every launch ends in a frozen window. Until distros ship 2.54, a JSC_useJIT=0 fallback in the Linux launcher (optionally gated on grep -q ' avx' /proc/cpuinfo failing, so machines with AVX keep the JIT) would make the app usable on this hardware, and the renderer-termination handling suggested above would at least surface the failure instead of a silent freeze.

[gokay-ai]

Implemented a guarded workaround in #3755.

On Linux x86_64, Buzz now checks readable CPU feature data before WebKit starts and sets JSC_useJIT=0 only when AVX is absent. Explicit user-provided JSC_useJIT values are preserved, and the existing dmabuf / --safe-rendering paths are unchanged.

The PR includes regression coverage for AVX-present/absent, user overrides, non-x86 architectures, and unreadable CPU data. This is intended as a compatibility mitigation until distributions ship a WebKitGTK stable release containing the upstream fix.