https://bugs.kde.org/show_bug.cgi?id=525861
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #3 from [email protected] --- Same crash here, on a different stack: KDE Plasma (KWin) Wayland instead of Hyprland, and an older KGuiAddons. So the race is not specific to 6.30 or to Hyprland. Environment: - Ubuntu 26.04.1 LTS, KDE Plasma Wayland session (KWin) - libkf6guiaddons6 6.24.0-0ubuntu1.1, Qt 6.10.2 - CopyQ 13.0.0 (Ubuntu package) Frequency: 16 CopyQ crashes recorded by systemd-coredump between 2026-08-15 and 2026-10-13 (13 SIGSEGV, 3 SIGABRT). Stack traces are available for the 8 most recent ones; 6 of these show the pattern below. Main thread (crashing). The offer's wl_proxy is already NULL when retrieveData() sends the receive request: #0 wl_proxy_get_version (proxy=NULL) rdi=0x0, mov 0x40(%rdi),%eax #1 libKF6GuiAddons.so.6 + 0x40b2f (DataControlOffer::retrieveData -> receive request, before pipe/poll/read) #2 libQt6Core.so.6 + 0x1d890a (QMimeData::retrieveData) #3 QMimeData::imageData() const (other cores: QMimeData::data(QString) const) #4..#7 copyq (no symbols) #8 KSystemClipboard::changed(QClipboard::Mode) ... At the same moment, another thread is destroying the offer while dispatching Wayland events: #7 QObject::destroyed(QObject*) #8 QObject::~QObject() #9 libKF6GuiAddons.so.6 + 0x3c966 (selection handler deleting the previous DataControlOffer) #10-#12 libffi / ffi_call #13-#14 libwayland-client #15 wl_display_dispatch_queue_pending Other variants seen in the cores, all in the same read path: - SIGSEGV at libKF6GuiAddons + 0x48168 / + 0x481aa / + 0x48199, inside QVariant copy and QHash code called from retrieveData (+0x40f4d) (the QHash::emplace variant reported above) - SIGSEGV at libKF6GuiAddons + 0x40851 - SIGABRT from glibc "unlink_chunk" heap-corruption checks, later in unrelated frees (QJSEngine teardown, CopyQ code). These are probably downstream heap corruption from the same use-after-free (not proven). So the race looks the same as in the original report: the thread that dispatches the data-control device's selection event deletes the old DataControlOffer (and its wl_proxy), while the GUI thread is still inside DataControlOffer::retrieveData() for a QMimeData that KSystemClipboard returned for that offer. Nothing checks for or guards against the offer being destroyed during the read. Checked workarounds: - Running CopyQ through XWayland (QT_QPA_PLATFORM=xcb) avoids this code path, but CopyQ then no longer receives clipboard changes from Wayland clients. So it is not a usable workaround. - Disabling Plasma's clipboard applet (Klipper) reduces how often the clipboard changes in quick succession; whether it lowers the crash rate is not verified yet. Core dumps are available if useful (no debug symbols for copyq/kguiaddons, but I can install dbgsym packages and re-symbolize). [Comment written by Claude Code] -- You are receiving this mail because: You are watching all bug changes.
