Cannot reproduce. Can you please attach a backtrace of the clipboard crash? The screen locker crash is likely to be different and will need to be tracked with a separate bug report. And please attach a backtrace for that one too. Thanks!

(In reply to Nate Graham from comment #1)

There is no segfault to get a backtrace, plasmashell simply aborts after:
> Error sending request: Broken pipe

This also occurs when I exit the screenlocker, which is why I reported it here.

Darn, that sucks.

Created attachment 144809 [details]
Backtrace from crashing clipboard

Hi,
I have the same problem. Plasma reliably crashes, when selecting text for the first time and the option "Synchronize contents of the clipboard and the selection" is activated.
Cheers, dietrich

Created attachment 144873 [details]
Debug log of klipper in infinite loop syncing selection and clipboard

I have the same problem in fedora 35 with plasmashell 5.23.3. I enabled debug output by changing /usr/share/qt5/qtlogging.ini to 

[Rules]
*.debug=true

To reproduce:
1. Log out and in again to make sure all qt5 apps picks up the new config.
2. Set "Synchronize contents of the clipboard and the selection" in the clipboard configuration. 
3. Select text

The log shows that klipper goes into a loop of synchronizing selection and clipboard that goes on for almost a full second, and does not stop until plasmashell exits.

Dec 26 09:36:39.307288 staslin konsole[98675]: qt.qpa.wayland.input: Setting frame event  QEvent::MouseButtonRelease
Dec 26 09:36:39.307333 staslin konsole[98675]: qt.qpa.wayland.input: Setting frame event  QEvent::MouseButtonPress
Dec 26 09:36:39.307803 staslin plasmashell[98114]: org.kde.klipper: Checking clip data
Dec 26 09:36:39.308117 staslin plasmashell[98114]: org.kde.klipper: Synchronize? true
Dec 26 09:36:39.308130 staslin plasmashell[98114]: org.kde.klipper: Setting clipboard to < "staslin" >
Dec 26 09:36:39.308272 staslin plasmashell[98114]: org.kde.klipper: Checking clip data
Dec 26 09:36:39.308293 staslin plasmashell[98114]: org.kde.klipper: Synchronize? true
Dec 26 09:36:39.308302 staslin plasmashell[98114]: org.kde.klipper: Setting selection to < "staslin" >
...
Dec 26 09:36:39.989223 staslin plasmashell[98114]: org.kde.klipper: Checking clip data
Dec 26 09:36:39.989293 staslin plasmashell[98114]: org.kde.klipper: Synchronize? true
Dec 26 09:36:39.989353 staslin plasmashell[98114]: org.kde.klipper: Setting selection to < "staslin" >
Dec 26 09:36:39.989418 staslin plasmashell[98114]: org.kde.klipper: Checking clip data
Dec 26 09:36:39.989481 staslin plasmashell[98114]: org.kde.klipper: Synchronize? true
Dec 26 09:36:39.989547 staslin plasmashell[98114]: org.kde.klipper: Setting selection to < "staslin" >
Dec 26 09:36:39.990078 staslin plasmashell[98114]: The Wayland connection broke. Did the Wayland compositor die?

$ grep "org.kde.klipper: Setting clipboard to" debug.log | wc -l 
1366
$ grep "org.kde.klipper: Setting selection to" debug.log | wc -l
1542

I looked more into this over the weekend. Adding the lame clipboard owner counter to newClipData() when in wayland and synchronize is set, makes it not crash at least.  It's not a nice fix, but i don't know how to find what triggers newClipData() on selection sync.

diff --git a/klipper/klipper.cpp b/klipper/klipper.cpp
index b090a2409..75a40264a 100644
--- a/klipper/klipper.cpp
+++ b/klipper/klipper.cpp
@@ -624,14 +624,31 @@ HistoryItemPtr Klipper::applyClipChanges(const QMimeData *clipData)
     return item;
 }
 
+// Protection against too many clipboard data changes. Lyx responds to clipboard data
+// requests with setting new clipboard data, so if Lyx takes over clipboard,
+// Klipper notices, requests this data, this triggers "new" clipboard contents
+// from Lyx, so Klipper notices again, requests this data, ... you get the idea.
+const int MAX_CLIPBOARD_CHANGES = 10; // max changes per second
+
 void Klipper::newClipData(QClipboard::Mode mode)
 {
+    qCDebug(KLIPPER_LOG) << "New clip data";
     if (m_locklevel) {
+        qCDebug(KLIPPER_LOG) << "Locked";
         return;
     }
 
     if (mode == QClipboard::Selection && blockFetchingNewData())
         return;
+    if (!KWindowSystem::isPlatformX11() && m_bSynchronize) {
+        if (m_overflowCounter == 0) {
+            m_overflowClearTimer.start(1000);
+        }
+        if (++m_overflowCounter > MAX_CLIPBOARD_CHANGES){
+            qCDebug(KLIPPER_LOG) << "Overflow";
+            return;
+        }
+    }
 
     checkClipData(mode == QClipboard::Selection ? true : false);
 }
@@ -643,12 +660,6 @@ void Klipper::slotHistoryChanged()
     }
 }
 
-// Protection against too many clipboard data changes. Lyx responds to clipboard data
-// requests with setting new clipboard data, so if Lyx takes over clipboard,
-// Klipper notices, requests this data, this triggers "new" clipboard contents
-// from Lyx, so Klipper notices again, requests this data, ... you get the idea.
-const int MAX_CLIPBOARD_CHANGES = 10; // max changes per second
-
 bool Klipper::blockFetchingNewData()
 {
 #if HAVE_X11

Cannot reproduce it anymore, should have been fixed with https://invent.kde.org/frameworks/kguiaddons/-/commit/55355eab1c8c2e823533ccfddde2bb97f27ceb0d