Bug 515465

Created attachment 189189 [details]
Git patch: Fix clipboard threading bug using QMetaObject::invokeMethod()

Fix attached as git-formatted patch.

The patch uses QMetaObject::invokeMethod() with Qt::BlockingQueuedConnection to safely marshal cross-thread calls back to the main thread, respecting Qt's threading requirements while preserving the synchronous API.

The fix:
- Detects when retrieveData() is called from a different thread (Wayland thread)
- Uses Qt's thread-safe invokeMethod to call fetchData() on the main thread
- Falls back to direct call when already on the main thread (fast path)
- Changes raw pointers to QPointer for null-safety

Tested on:
- KDE Plasma 6.5.5
- openSUSE Tumbleweed 20260131
- Qt 6.10.1

Results:
- Eliminates 100% reproducible crash
-  Clipboard works bidirectionally
-  No threading warnings
-  Klipper integration works correctly

The patch can be applied with:
  git apply 0001-fix-clipboard-threading-bug-515465.patch

Or reviewed/merged directly into the repository.

Please submit patches via https://invent.kde.org

>ext_data_control_source_v1_send

The stack trace has no correlation to everything else in the commentary. 

Someone is copying from the data from the portal, not the portal reading the clipboard 
It's worth noting the mimedata is guarded with a mutex. Clearly something is broken, but not related to what you've written.  Mimedata access is guarded.

If it is AI written, please don't. I would rather have less text than wrong text.

>https://github.com/gregcman/lamco-rdp-server

This doesn't load, is it private?

here's the affected versions information according to my quick checking: 

Bug introduced: v6.3.90 (May 15, 2025)                                                                                     
Affected range: v6.3.90 → v6.5.5 (current)                                                                                 
Duration: 9 months, ~19 releases                                                                                           
Fix target: v6.5.6 or v6.6.0

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
greg@lamco.io
https://www.lamco.ai

Re: the mutex: I see m_selectionLock in WaylandClipboard::mimeData(), but                                            
  DataControlSource::ext_data_control_source_v1_send() (waylandclipboard.cpp:370) calls m_mimeData->data() without holding a lock.                                                                                                                      
                                                                                                                             
  The crash occurs in ext_data_control_source_v1_send on the Wayland thread. Should this code path be holding m_selectionLock before accessing m_mimeData?                                                                                              
                                                                                                                             
  I can build with debug symbols and provide detailed backtrace if that would help clarify the root cause.

>  I can build with debug symbols and provide detailed backtrace if that would help clarify the root cause.

No, I think it's clear from the original trace.

*** Bug 515433 has been marked as a duplicate of this bug. ***

Additional threading issue found during testing:                                                                           
                                                                                                                             
  Portal emits SelectionTransfer signal from wrong thread, preventing D-Bus signal delivery.                                 
                                                                                                                             
  Journal log shows:                                                                                                         
    QtDBus: cannot relay signals from parent DesktopPortal(0x564f27001aa0 "")                                                
    unless they are emitted in the object's thread QThread(0x564f23a4f1d0 "Qt mainThread").                                  
    Current thread is QThread(0x564f2592f270 "").                                                                            
                                                                                                                             
  This occurs when SetSelection is called and portal needs to request data from the application. The signal is emitted from a worker thread instead of the main thread, so D-Bus blocks it.                                                             
                                                                                                                             
  Result: SelectionWrite never receives the signal, portal times out after 1 second, clipboard operation fails.              
                                                                                                                             
  This appears related to the same threading architecture issue. Fixing the threading model for clipboard operations may resolve both issues.

LEt me know if you would like any further information.

Thanks,
Greg Lamberosn

A possibly relevant merge request was started @ https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/517

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kguiaddons/-/merge_requests/207

Git commit 2c0d063e5773b9c30afe3d96b9c2f910cf3bcbc3 by David Redondo.
Committed on 04/02/2026 at 10:00.
Pushed by davidre into branch 'master'.

clipboard: Run data fetching in the correct thread

KSystemClipboard changed so it now runs in a separate thread. Because
we override retrieveData of our QMimeData this runs in this new thread
now. As a short term fix make it run in the correct thread again.
Longer term we should port it to use data control directly without the
intermediate layer of KSystemClipboard.

M  +3    -1    src/clipboard.cpp

https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/2c0d063e5773b9c30afe3d96b9c2f910cf3bcbc3

A possibly relevant merge request was started @ https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/518

Git commit 475741c26cbed5c40ddd6257400b9ed493495235 by David Redondo.
Committed on 04/02/2026 at 13:41.
Pushed by davidre into branch 'Plasma/6.6'.

clipboard: Run data fetching in the correct thread

KSystemClipboard changed so it now runs in a separate thread. Because
we override retrieveData of our QMimeData this runs in this new thread
now. As a short term fix make it run in the correct thread again.
Longer term we should port it to use data control directly without the
intermediate layer of KSystemClipboard.


(cherry picked from commit 2c0d063e5773b9c30afe3d96b9c2f910cf3bcbc3)

Co-authored-by: David Redondo <kde@david-redondo.de>

M  +3    -1    src/clipboard.cpp

https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/commit/475741c26cbed5c40ddd6257400b9ed493495235