https://bugs.kde.org/show_bug.cgi?id=515465
--- Comment #5 from Greg Lamberson <[email protected]> --- Hey David, Yes', I'm trying to hurry, but there is correlation. LEt me explain. The crash occurs in the Wayland thread when Klipper requests clipboard data FROM our clipboard source: Thread 2450 (Wayland thread): #6 _ZNK9QMimeData4dataERK7QString (libQt6Core.so.6) #7 0x00007f0bab929f2c (libKF6GuiAddons.so.6 + 0x40f2c) #8 0x00007f0bab91f468 (libKF6GuiAddons.so.6 + 0x36468) … #17 0x00007f0bab923626 (libKF6GuiAddons.so.6 + 0x3a626) ← ClipboardThread::run **Source code correlation (from kguiaddons waylandclipboard.cpp):** Frame #7 (offset 0x40f2c) corresponds to DataControlSource::ext_data_control_source_v1_send: ```cpp // waylandclipboard.cpp:346-371 void DataControlSource::ext_data_control_source_v1_send(const QString &mime_type, int32_t fd) { // ... ba = m_mimeData->data(send_mime_type); // ← Line 370, calls QMimeData::data() // ... } Frame #17 (offset 0x3a626) corresponds to ClipboardThread::run (Wayland event loop). But you're correct. the direction is: Klipper -to- reads FROM -to- our DataControlSource NOT “portal reading clipboard”. The sequence is: lamco-rdp-server calls SetSelection (announces clipboard) portal-kde creates PortalMimeData KSystemClipboard wraps it in DataControlSource on Wayland thread Klipper (monitoring clipboard) requests to READ from our source Compositor calls ext_data_control_source_v1_send on Wayland thread Tries to access PortalMimeData → CRASH The Threading Issue My analysis focused on PortalMimeData::retrieveData() accessing main-thread objects, but I need to clarify: The crash happens in QMimeData::data() BEFORE retrieveData() is called. This suggests the QMimeData object itself may be invalid/corrupted when accessed from the Wayland thread, not just the retrieveData() implementation. Possible causes: PortalMimeData moved to Wayland thread violates QObject threading Race condition where PortalMimeData is deleted while callback pending Qt internals not thread-safe when QMimeData moved across threads I used AI tools (Claude) to help analyze the ~2000 lines of source code and correlate the stack trace, but the analysis is based on: Actual source code from xdg-desktop-portal-kde v6.5.5 Actual source code from kguiaddons Real crash coredumps from production testing Reproducible crash (100% on every SetSelection call) I’m happy to provide more details, run additional tests, or refine the analysis based on your feedback. Reproducibility The crash is 100% reproducible on KDE Plasma 6.5.5 with Klipper enabled (default). Test application: https://github.com/gregcman/lamco-rdp-server (currently private, can make specific test case public if helpful) Questions for You Is the threading explanation incorrect? Should QMimeData be safe to move across threads? Could this be a QMimeData lifecycle issue instead (object deleted while callback pending)? Would you like me to build with debug symbols and provide more detailed backtrace? Should I test with specific Qt/KDE debug flags enabled? I want to make sure the fix addresses the actual root cause, not just symptoms. Please let me know what you think as this, I believe, is the correct way to harmoniously interact with Klipper for everybody instead of trying to fight it. Thanks, Greg Lamberson Lamco Development [email protected] https://www.lamco.ai -- You are receiving this mail because: You are watching all bug changes.
