Created attachment 150823 [details] try open this file When opening attached hang-final.docx LibreOffice Writer hangs with 100% CPU. It is possible to scroll to the middle of the document and after that nothing can be done. Version: 6.1.5.2 Build ID: 1:6.1.5-0ubuntu0.18.10.1 Older version opens the same document without problems, more specifically it is 5.1.6.2, 1:516~rc2-0ubuntu1~xenial6
Hello, Thanks for reporting this issue. This is a duplicate of bug 119253 and it's fixed in LibreOffice 6.2.3 *** This bug has been marked as a duplicate of bug 119253 ***
I downloaded 6.2.4.2 and it still hangs on this file
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
Created attachment 151706 [details] screenshot same result
LibreOfficeDev_6.3.0.0.alpha1_Linux_x86-64_deb same result
I have tested 6.2.4.2 Windows version - same problem
(In reply to kkivi from comment #5) > LibreOfficeDev_6.3.0.0.alpha1_Linux_x86-64_deb > > same result Could you please paste the info from Help - about LibreOffice ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the information has been provided
Version: 6.3.0.0.alpha1+ Build ID: 40e2a0d7039eee9c5377996da3949680903e1016 CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-05-22_13:55:35 Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
I can't confirm it with Version: 6.3.0.0.alpha1+ (x64) Build ID: e92dcfdc7bd7b237e0bee26ff226a102d9e8e766 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-05-14_00:00:57 Locale: en-US (de_DE); UI-Language: en-US Calc: threaded Takes less than 10 sec to open file.
>>I can't confirm it with Try to scroll it back and force. It will get stuck. Watch CPU LOAD at the same time
(In reply to kkivi from comment #10) > Try to scroll it back and force. It will get stuck. > Watch CPU LOAD at the same time Using touchpad fro scrolling CPU is around 33% at maximum. It hangs for several seconds. But I can't confirm CPU 100%.
Created attachment 151789 [details] screenshot 100% CPU This is 100% CPU screenshot from Linux. We use different operating systems, so there may be a difference in details. I cannot work with this (short) file. Can you?
I feel I must add, that I do not agree with the renaming this bug. Under Linux, it is an absolute disaster, it barely manages to load the first page
Hi kkivi, Many performance improvements has been done recently. Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ?
6.4 alpha still runs at 100% CPU when I move down below page 25
Created attachment 152530 [details] 6.4 version proof
I believe that this could not be fixed by general performance improvements. I think the table parsing algorithm should be revised. As I said, version 5.1.6.2 opens this file without any problem
[Automated Action] NeedInfo-To-Unconfirmed
I am not able to reproduce the issue Version: 6.3.1.2 Build ID: 6.3.1-1 CPU threads: 4; OS: Linux 5.2; UI render: default; VCL: gtk3; Locale: it-IT (en_GB.UTF-8); UI-Language: en-GB Calc: threaded
(In reply to mattia.b89 from comment #19) > I am not able to reproduce the issue > > Version: 6.3.1.2 > Build ID: 6.3.1-1 > CPU threads: 4; OS: Linux 5.2; UI render: default; VCL: gtk3; > Locale: it-IT (en_GB.UTF-8); UI-Language: en-GB > Calc: threaded NO, I have this issue too!
I do confirm it in Version: 6.4.0.0.alpha0+ Build ID: 186d36a7036462ae641b35004b4ffba3eeeca46f CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded it hangs in page 17/18 using page av key
OTOH, not reproducible in Version: 5.2.0.0.alpha1+ Build ID: 5b168b3fa568e48e795234dc5fa454bf24c9805e CPU Threads: 4; OS Version: Linux 4.15; UI Render: default; Locale: ca-ES (ca_ES.UTF-8)
Also reproducible in Version: 5.4.0.0.alpha1+ Build ID: 9feb7f7039a3b59974cbf266922177e961a52dd1 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group
I reproduced this bug on a new computer with 32GB of RAM. soffice.bin consumes 12GB ( on a file that was easily handled by version 5) Is there any hope, that this issue will be addressed?
(In reply to Xisco Faulí from comment #21) > I do confirm it in > > Version: 6.4.0.0.alpha0+ > Build ID: 186d36a7036462ae641b35004b4ffba3eeeca46f > CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; > Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US > Calc: threaded > > it hangs in page 17/18 using page av key No longer reproducible in Version: 6.5.0.0.alpha0+ Build ID: 1abfc8e2f677024ea058e96f3133e503ba89ea02 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded 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.
No repro with Version: 6.5.0.0.alpha0+ (x64) Build ID: 42a1a1c6b91907f81e15066ffab219411f18c4db CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: GL; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
(In reply to Xisco Faulí from comment #25) > 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 'NEW' if the bug is still present in the master build. Change status to RESOLVED WORKSFORME, if the problem went away.
two people couldn't reproduce it in master. I think we can already close it as RESOLVED WORKSFORME
Also fixed in Version: 6.4.0.1.0+ Build ID: 956231069ef97113fc398dd61804fde0101ea746 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: x11; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded
The issue got fixed by https://cgit.freedesktop.org/libreoffice/core/commit/?id=2c918aa51e5528b090e52fa31b10fa17cf2593ae @László, thanks for fixing this issue!
(In reply to Xisco Faulí from comment #30) > The issue got fixed by > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=2c918aa51e5528b090e52fa31b10fa17cf2593ae > > @László, thanks for fixing this issue! @Xisco: That's not a general fix for DOCX layout dead locks, but document handling is more like a little like MSO does, so I hope, too, there will be fewer problems... Thanks!
(In reply to László Németh from comment #31) > (In reply to Xisco Faulí from comment #30) > > The issue got fixed by > > https://cgit.freedesktop.org/libreoffice/core/commit/ > > ?id=2c918aa51e5528b090e52fa31b10fa17cf2593ae > > > > @László, thanks for fixing this issue! > > @Xisco: That's not a general fix for DOCX layout dead locks, but document > handling is more like a little like MSO does, so I hope, too, there will be > fewer problems... Thanks! Yep, I was a bit surprise of the result too. Probably other changes helped as well, but your commit definitely helped as well. Thanks!
I can confirm that development version 6.5 opens the example document without a problem. Unfortunately, there is still an issue ( though less severe - 100% CPU and hangs for about a minute during repagination in the middle of the document ) with the original document. I cannot post it here, but I will try to amend it to demonstrate the problem.
Created attachment 157047 [details] seconf example version 6.5 hangs for a minute on the original document ( with Warning message "application doesn't respond"). However, things are much better - after the initial load I can finally scroll and edit freely. I can also save it in odt format which has no further problems. I attached an amended document, which freezes shortly when scrolled to page 27-28 for the first time. What status should be set on this bug, given this new information?
Created attachment 157151 [details] new 3 minutes hang This version causes 6.5 to hang at page 20 for at least 3 minutes with gnome message box stating that "application not responding"
There is an example ( in previous comment) which demonstrates that bug still exists in version 6.5
(In reply to kkivi from comment #35) > Created attachment 157151 [details] > new 3 minutes hang > > This version causes 6.5 to hang at page 20 for at least 3 minutes with > gnome message box stating that "application not responding" I bibisected with win32-5.3 repo to https://git.libreoffice.org/core/+/8a800eea613c0f5ad3302136766791dc58880fb3%5E!/ tdf#104425 sw: split rows w/large min height (fix layout loop) Adding Cc: to Mike Kaganski
issue seems gone for me (tried with file attached here) Arch Linux w/ libreoffice-fresh 6.4.4-1
(In reply to mattia.b89 from comment #38) > issue seems gone for me (tried with file attached here) > > Arch Linux w/ libreoffice-fresh 6.4.4-1 It's not gone, if you try with attachment 157151 [details] Arch Linux 64-bit Version: 7.1.0.0.alpha0+ Build ID: 2bccbd2ba6c90d5e02285629c2b079c35260c08b CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 3 June 2020
(In reply to Buovjaga from comment #39) > (In reply to mattia.b89 from comment #38) > > issue seems gone for me (tried with file attached here) > > > > Arch Linux w/ libreoffice-fresh 6.4.4-1 > > It's not gone, if you try with attachment 157151 [details] > > Arch Linux 64-bit > Version: 7.1.0.0.alpha0+ > Build ID: 2bccbd2ba6c90d5e02285629c2b079c35260c08b > CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: gtk3 > Locale: fi-FI (fi_FI.UTF-8); UI: en-US > Calc: threaded > Built on 3 June 2020 correction: with that file LO hangs
Situation has improved, only attachment 3, so attachment 157151 [details] still slow Version: 7.1.0.0.alpha1+ (x64) Build ID: 312a33b7636334f6ce3b6d1702bc5d3e45215601 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
This bug should've been closed when original issue of attachment 150823 [details] was resolved. It's wrong to add more different examples. 3rd sample DOCX attachment 157151 [details] is LO created, which is also wrong (acceptable is ODT saving and reopening as DOC/X but we don't have ODT). I had MSO crash on open and again on save. Still I could normally scroll all 60 pages in LO 7.2+ without special hang, just somewhat higher CPU. Note that immediate and relentless holding of PageDown can crash it, but this is long table and tables in Writer are anyway not CPU efficient. I see high CPU with 5.3 oldest so I don't see how that one is regression. So I close this.
Similar but more clear is Bug 125171.
(In reply to Timur from comment #42) > This bug should've been closed when original issue of attachment 150823 [details] > [details] was resolved. It's wrong to add more different examples. > > 3rd sample DOCX attachment 157151 [details] is LO created, which is also > wrong (acceptable is ODT saving and reopening as DOC/X but we don't have > ODT). I had MSO crash on open and again on save. > Still I could normally scroll all 60 pages in LO 7.2+ without special hang, > just somewhat higher CPU. Note that immediate and relentless holding of > PageDown can crash it, but this is long table and tables in Writer are > anyway not CPU efficient. > I see high CPU with 5.3 oldest so I don't see how that one is regression. > So I close this. I would like to note the last example is just a more accurate representation of the original example, that I could not include for the obvious reason. The document has the same structure better resembles the original in regard to word boundaries. I object to closing this bug
Original issue is not reproducible. Another issue should be elsewhere. Seems that problem is in saving in LO, because 3rd sample DOCX attachment 157151 [details] is LO created and attachment 172773 [details] in bug 142773 was created from this bug 124795 (just anonymized table from attachment 150823 [details]). So let's continue there.