Created attachment 134676 [details] zip file with test documents and several screenshots In LO Writer from builds younger (!) than libo-master64~2017-07-12_23.21.39_LibreOfficeDev_6.0.0.0.alpha0_Win_x64.msi resp. libo-master~2017-07-13_05.02.25_LibreOfficeDev_6.0.0.0.alpha0_Win_x86.msi I have the problem, that Writer "freezes", when I make some changes in my edited documents. Writer doesn't answer and in the Task Manager I see, that the program uses many cpu capacity. Sometimes the programs wakes up alone after a certain time (some minutes) without any actions, but mostly it doesn't. But I have seen, that it wakes up often (but not allways) after I have made and saved a screenshot with "Snipping Tool". Then cpu of LibreOffice decreases to 0 or near 0 and Writer answers again. For demonstration I have edited my test document "Test_Altix V - Abbau des Kameradeckels.odt" (in the attached zip file) without any problems with Version: 6.0.0.0.alpha0+ Build ID: d9e8fdbcd2f834a483890b409ede1b44c2da5da3 CPU threads: 1; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-07-13_05:02:25 Locale: de-DE (de_DE); Calc: group The saved document with my changes is "Test_edited+saved_Altix V - Abbau des Kameradeckels.odt" (also in the zip file). Than I have tried to do the same with Version: 6.0.0.0.alpha0+ (x64) Build ID: f054b9187155bc32b7d06808aea87127cb0a3a4f CPU threads: 2; OS: Windows 6.19; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-07-15_22:51:09 Locale: de-DE (de_DE); Calc: group and Version: 6.0.0.0.alpha0+ Build ID: c7fe625c8d41f648f89765abc40bb7b8fd4ed12a CPU threads: 1; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-07-16_02:04:02 Locale: de-DE (de_DE); Calc: group and I got the freezes, see several screenshots in "Screenshot_x64_*.*_(Loop)_Writer_Problem.JPG" (also in the zip files). I have tested on both an old computer with x86 cpu and a newer with x64 cpu. Steps to reproduce: - open "Test_Altix V - Abbau des Kameradeckels.odt" - copy the lines according to "Screenshot_1_Writer_Problem.JPG" at the end of the document (see "Screenshot_2_Writer_Problem.JPG") - change the copied lines according to "Test_edited+saved_Altix V - Abbau des Kameradeckels.odt" resp. "Test_edited+saved_Altix V - Abbau des Kameradeckels.pdf" (= odt document exported to pdf) - after one enters some characters Writer stops, not answers on any actions, but uses many cpu time (only with "younger" builds of LO) - when Writer freezes longer, making a screenshot may help to wake up Writer
Confirming with: Version: 6.0.0.0.alpha0+ Build ID: c7fe625c8d41f648f89765abc40bb7b8fd4ed12a CPU threads: 4; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-07-16_02:04:02 Locale: nl-NL (nl_NL); Calc: CL Did notice the same/similar behavior bug 109148
In my tests was the German language pack active (spelling, hyphenation, thesaurus - dict-de_de-frami_2015-12-28.zip). Because of Comment 3 in bug 109148 I have repteated my tests (see descripion: Steps to reproduce) without any extensions in LO on 2 computers (x86 and x64) with actual builds for Windows (libo-master64~2017-07-17_02.24.14_LibreOfficeDev_6.0.0.0.alpha0_Win_x64.msi resp. libo-master~2017-07-16_23.03.56_LibreOfficeDev_6.0.0.0.alpha0_Win_x86.msi). On both computers I can reproduce the behavior. But there is a difference: All phases that LO Write was unresponsive have ended without any user action after about 5 until max. 10 minutes and after a total time of about 1 hour (x86, about 5 times unressponsive) resp. 15 minutes (x64, 2 times unreespnsive) I could save the changed documents.
I expect it to be fixed in the upcoming daily build. https://bugs.documentfoundation.org/show_bug.cgi?id=109123#c6
In test with Version: 6.0.0.0.alpha0+ (x64) Build ID: a9588baca8137f51e2ca72e40b1f448b0e1885d1 CPU threads: 2; OS: Windows 6.19; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-07-21_04:09:11 Locale: de-DE (de_DE); Calc: group the problem exists no longer.
(In reply to Stefan_Lange_KA@T-Online.de from comment #4) > the problem exists no longer. In that case, just resolve with WFM.
*** This bug has been marked as a duplicate of bug 109123 ***