Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. 
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
(Please note that the attachment will be public, remove any sensitive information before attaching it. 
See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)

unfortunatly this is a very random occuring bug, so I have not pointed a specific document yet.

Created attachment 170328 [details]
sample document

I might have found a buggy scenario.

You must be on Kubuntu (maybe) 
You setup klipper to only have an history count of 1 (paste buffer history count)

you start writer
you open the joined doc
you select a few word in it
you press ctrl-c (to copy)

then you close the writer window with the X on the corner
=> crash

bugs #140700 #140698  might be related

(In reply to Pascal from comment #3)
> You setup klipper to only have an history count of 1 (paste buffer history
> count)
> 
> you start writer
> you open the joined doc
> you select a few word in it
> you press ctrl-c (to copy)
> 
> then you close the writer window with the X on the corner
> => crash

I can reproduce a crash using those steps (just selected the "Lorem ipsum" for "a few words")  on Debian testing with a current master build, though my backtrace is different.

Doesn't crash after increasing klipper history size to be larger than 1.

Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: c7b898df4d452746399621f6adc8e7da088f0f3a
CPU threads: 12; OS: Linux 5.10; UI render: default; VCL: kf5
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

@Pascal: Setting bugs to status NEW should be done by a person independent from the original reporter, please set from NEEDINFO to UNCONFIRMED next time when answering a question on a bug that hasn't been confirmed by somebody else yet.

Didn't crash in a quick test with gtk3 VCL plugin and otherwise same version as in comment 5.

(In reply to Pascal from comment #3)
> Created attachment 170328 [details]
> sample document
> 
> I might have found a buggy scenario.
> 
> You must be on Kubuntu (maybe) 
> You setup klipper to only have an history count of 1 (paste buffer history
> count)
> 
> you start writer
> you open the joined doc
> you select a few word in it
> you press ctrl-c (to copy)
> 
> then you close the writer window with the X on the corner
> => crash

This looks like bug 140700, isn't it ?
Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ?
You can install it alongside the standard version.
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build

(In reply to Xisco Faulí from comment #7)
> This looks like bug 140700, isn't it ?
> Could you please try to reproduce it with a master build from
> http://dev-builds.libreoffice.org/daily/master/ ?

It really sounds similar, but is different. The version I used in comment 5 already includes the fix for tdf#140700, but it still crashes for the scenario described here.

So I had a look at this, because I was fixing bug 140404 and was already in the clipboard code. I can't repo any of the crashes with the steps on Debian buster with current master, from any comment. But then there are more Klipper options, like the sync of PRIMARY and CLIPBOARD, which might trigger other code. I checked it doesn't trigger the fix for bug 140404, just in case.

Bug 140700 is about Calc and nothing in this bugs bt (attachment 170141 [details]) indicates Calc and ~SwTransferable() already has equivalent code to the Calc fix:

    SwModule* pMod = SW_MOD();
    if(pMod)

My current idea is, that these kind of bugs are triggered by the workaround for bug 131533. We defer the real clipboard clear handling, but no LO code really expects that. Everything is refcounted, so it should work.
And I can't repo the crash from bug 131533 anymore, if I revert that fix, but the bug 131533 terminal message "QXcbClipboard::setMimeData: Cannot set X11 selection owner" still appears. That also shouldn't be a result from the fix for bug 140700, because bug 131533 was involving Draw, but since I can't repo and it has no attached bt...

So I thought to test Application::IsQuit to catch the shutdown and skip deference, in this case, but that returns false on quit too. Seems Application::Quit is called much later :-(

If someone can repo the crash and has a build, can you check, if 

$ git revert 313081c0703c66918e95640c74cd57312a1e8bba

fixes the crash?

Created attachment 171000 [details]
Backtrace with 313081c0703c66918e95640c74cd57312a1e8bba reverted

While trying to reproduce, I realized that it doesn't always crash, but depends on how selection is done.

It crashes for this case (the "Lorem Ipsum" used here is the one from the first heading):

0) set Klipper history size to 1, open sample doc
1) double-click on "Lorem" -> "Lorem" gets selected
2) press Shift key + click after the "ipsum" -> "Lorem Ipsum" is selected
3) close LO

It does not crash when doing any of the following instead of steps 1-2:

* press Shift + click after "ipsum" -> "Lorem ipsum" is selected (cursor initially is at the beginning of the doc)
* select "Lorem ipsum" by clicking before the "Lorem", then moving the mouse cursor to after the "ipsum" while keeping the mouse button pressed
* leave out step 2, i.e. only double-click "Lorem" before Ctrl+C and closing the doc

(In reply to Jan-Marek Glogowski from comment #9)
> 
> If someone can repo the crash and has a build, can you check, if 
> 
> $ git revert 313081c0703c66918e95640c74cd57312a1e8bba
> 
> fixes the crash?

Well, I get a crash with a different backtrace (attachment 171000 [details]), which may or may not be what 313081c0703c66918e95640c74cd57312a1e8bba had fixed.

@jmux: Adding you in CC due to your question in comment 9 and answer in comment 11, please remove yourself again as needed.

Created attachment 171002 [details]
My tested plasma klipper settings

(In reply to Michael Weghorn from comment #11)
> 0) set Klipper history size to 1, open sample doc
> 1) double-click on "Lorem" -> "Lorem" gets selected
> 2) press Shift key + click after the "ipsum" -> "Lorem Ipsum" is selected
> 3) close LO

No repo. But then your STR doesn't have any more Ctrl+C, like before, but even if I add that before the close (using the window X or Ctrl+w), no crash. Master source + the revert AKA no clean defer.

Maybe it is actually some Qt bug. I'm using Debian Buster, with an old Qt 5.11.3+dfsg1-1+deb10u4. Or a KF5 bug.

But then I couldn't repo bug 131533 with my sample Qt app, so I'm still suspicions, that there is some underlying problem we actually worked around.

(In reply to Jan-Marek Glogowski from comment #13)
> (In reply to Michael Weghorn from comment #11)
> > 0) set Klipper history size to 1, open sample doc
> > 1) double-click on "Lorem" -> "Lorem" gets selected
> > 2) press Shift key + click after the "ipsum" -> "Lorem Ipsum" is selected
> > 3) close LO
> 
> No repo. But then your STR doesn't have any more Ctrl+C, like before, but
> even if I add that before the close (using the window X or Ctrl+w), no
> crash. Master source + the revert AKA no clean defer.

My bad, the Ctrl+C between step 2) and 3) is still needed.

HEllo

no more bug with 7.4.6.2
in kubuntu 22.10