https://bugs.kde.org/show_bug.cgi?id=522547
--- Comment #10 from [email protected] --- Confirming this on 6.7.5 / KF 6.30.0. A client-side fix is not sufficient. Environment EndeavourOS (Arch), Wayland session plasma-workspace 6.7.5-1, plasma-integration 6.7.5-1 kwin 6.7.5-1, kwindowsystem 6.30.0-1, Qt 6.11.2-3 Intel Arc / Arrow Lake-P iGPU, Mesa 26.2.3, kernel 7.2.6 The thread already has AMD and NVIDIA reports, so this is not driver specific. Frequency and trigger The reliable trigger here is right-clicking a widget in the panel (I notice it on the system monitor widget) - i.e. any short-lived blurred popup. In the retained journal covering 17-25 September: 32 x plasmashell: "tried to set blur region on destroyed surface" 32 x plasmashell: "The Wayland connection experienced a fatal error: Protocol error" 32 x systemd: Main process exited, code=exited, status=255/EXCEPTION 32 x systemd: Scheduled restart job All 32 restarts were preceded by a blur error within 60 seconds. It is bursty rather than steady - the daily counts were 6, 12, 3, 2, 3, 2, 3, 0, 1 - and KWin itself never dies. Confirming comment 8: nothing lands in coredumpctl, because the client exits with a status code rather than on a signal. (1) A client-side fix was attempted and is not sufficient I patched kwindowsystem's WindowEffects::installBlur() to key the cached effect object on the wl_surface it was created from: struct BackgroundEffectData { std::unique_ptr<BackgroundEffect> effect; wl_surface *surface = nullptr; }; ... auto &data = m_backgroundEffects[window]; if (!data.effect || data.surface != surface) { data.effect = std::make_unique<BackgroundEffect>( m_backgroundEffectManager->get_background_effect(surface)); data.surface = surface; } so a cached object is never reused for a different surface. That build was installed and verified to be the one in use - the sha256 of the installed libKF6WindowSystem.so.6.30.0 matched the built package, and the plasmashell that died was running with it mapped. It was still killed days later with the identical error. The reason is that pointer identity is not object identity: when Qt frees the wl_surface proxy, the allocator can hand the same address to a newly created surface, so the check passes while the surface behind the cached effect object is a different, already destroyed one. The client therefore needs a lifetime-aware handle rather than a pointer comparison - and, more practically, the compositor is the right place to fix this, since it is the only party that knows for certain whether the surface is still alive. (2) Compositor-side: the object can simply be ignored This is what comment 0 proposed, and it is safe because a blur region for a destroyed surface carries no information - dropping it loses nothing: void ExtBackgroundEffectSurfaceV1::ext_background_effect_surface_v1_set_blur_region(Resource *resource, wl_resource *region) { if (!m_surface) { // was: wl_resource_post_error(resource->handle, error_surface_destroyed, ...) return; } ... in src/wayland/backgroundeffect_v1.cpp. That call site is the only place this error is raised (the string occurs exactly once in the built libkwin), so with the change the failure mode cannot occur at all, rather than merely becoming rarer. Blur regions requested for a live surface are unaffected. I have had this running since today (2026-09-25) and will report back if anything shows up. One related note for whoever fixes this: the other error in the same file, error_background_effect_exists from get_background_effect(), is probably better left fatal. Ignoring it would leave the client holding an object id the server never created, and its next request on that object would fail in a worse way. Only the destroyed-surface case is safe to ignore. For anyone trying to reproduce: the blur capability is only advertised while the Blur effect is loaded - BlurEffect's constructor calls backgroundEffectManager()->addBlurCapability() and its destructor calls removeBlurCapability() - and the client does not send blur requests at all while the capability is absent. That is why switching Blur off removes the symptom entirely rather than just masking it, and it also means a third-party effect that calls addBlurCapability() keeps the bug reachable even with the stock Blur effect disabled. -- You are receiving this mail because: You are watching all bug changes.
