Description: My wife writes her Master's thesis with LibreOffice, and when she copy-pastes some text within the document, Writer may, or may not, hang after pressing Ctrl+C. This happens with some text only, sometimes we can narrow this down to a particular word that needs to be copy-pasted for the issue to be triggered. The issue can be reliably reproduced. The text that triggers this may be different (like, in different places of the document), but once the nasty snippet is found, copying it each time triggers the bug. The issue manifests in Writer going completely unresponsive just burning the CPU. I've managed to collect two cores / stacktraces, one on my wife's laptop where the issue can be triggered reliably, another one is on my desktop, where it can take some time after selecting the text and copying it for the bug to occur (the text remains selected, and I just watch Writer waiting for it to become unresponsive). We both have the same distro with the same set of packages, so I don't know why it is harder to reproduce the bug on my desktop. I will attach stack traces as separate files. Steps to Reproduce: 1. select some text 2. hit Ctrl+C Actual Results: Writer goes unresponsive burning CPU. Expected Results: Copy-paste should just work. Reproducible: Sometimes User Profile Reset: Yes Additional Info: It's libreoffice-fresh from Arch Linux, everything is up-to-date.
Created attachment 193852 [details] Writer core from wife's laptop
Created attachment 193853 [details] Writer core from my desktop
I do have actual cores saved as well, so I can peek into them further and provide any additional information needed.
We both use KDE 6.
Perhaps some clipboard manager interfering?
We don't have any 3rd-party clipboard manager except the one KDE offers ("Clipboard Contents" in the systray). I tried marking it as "Disabled", but it didn't help.
Also, we use SAL_USE_VCLPLUGIN=gtk3 due to https://bugs.documentfoundation.org/show_bug.cgi?id=160416 / https://bugs.documentfoundation.org/show_bug.cgi?id=160565 / https://bugs.documentfoundation.org/show_bug.cgi?id=160624 The issue is reproducible with SAL_USE_VCLPLUGIN=kf6 too, but it may happen that it is triggered on Writer closure. With SAL_USE_VCLPLUGIN=kf6 the top part of the stack looks very similar.
Created attachment 193854 [details] Stacktrace with SAL_USE_VCLPLUGIN=kf6
I've also managed to collect `perf` data for `soffice.bin` burning CPU: ``` # perf record -ag -p $(pidof soffice.bin) # …wait ~10 seconds… # perf report --sort=comm --stdio … # Children Self Command # ........ ........ ............... # 99.97% 99.97% soffice.bin | ---(anonymous namespace)::HTMLEndPosLst::InsertNoScript(SfxPoolItem const&, int, int, std::set<std::unique_ptr<SwHTMLFormatInfo, std::default_delete<SwHTMLFormatInfo> >, comphelper::UniquePtrValueLess<SwHTMLFormatInfo>, std::allocator<std::unique_ptr<SwHTMLFormatInfo, std::default_delete<SwHTMLFormatInfo> > > >&, bool) [clone .part.0] … ``` This stuff seems to be a part of `/usr/lib/libreoffice/program/libswlo.so`.
I can reproduce this with `LibreOffice-fresh.basic-x86_64.AppImage` as well. But it seems I cannot reproduce this with `LibreOffice-still.basic-x86_64.AppImage`.
Created attachment 193859 [details] Minimal reproducer Attaching minimal reproducer. For me to trigger the issue it's enough to open this file, press Ctrl+A to select everything, then press Ctrl+C to copy the selection, and then Writer goes unresponsive burning CPU. LO "fresh" is affected, LO "still" doesn't seem to be affected.
Reproducible with: Version: 24.2.2.2 (X86_64) / LibreOffice Community Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: default; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded It seems that the problem originates in the footnote, with the removal of the footnote, the problem disappears. Recreating the footnote, the issue, is not reproduced. The file doesn't pass well the validator. https://odfvalidator.org/ But not reproducible with: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ea43cbbb7371a743f470d949762a0e92f196e652 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
Thank you for checking this. I'm not sure how this document can fail validation as it was not modified outside of Writer. Regarding the footnote, I think she did not enter the text of the footnote by herself but instead copy-pasted it from a site that generates formatted bibliography string (Grafiati). I shortened the string of course to the point of a minimal reproducer.
I do not think this is an issue with footnotes per se. In the past I was able to encounter the same issue while copy-pasting an ordinary word with no footnote attached. I no longer have that text excerpt unfortunately.