Created attachment 133868 [details] Screen shot of after 17hours How to reproduce. Set page margins to 3mm Create a table with 82 columns, 2 rows. Set row height to 2.5mm. Go to a cell in the second row, add 104 rows above it. It takes hours create and render the table on the screen, And LibreOffice remains unresponsive for at least 17 hours, possibly indefinitely.
Thank you for reporting the bug. it seems you're using an old version of LibreOffice. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Tried in 5.3.3.2. Followed the procedure on adding 104 rows LO 5.3.3.2 did this: Created and drew the table on the screen almost immediately. Then hammered the CPU core for upto 90minutes before generating a segment fault.
Could you please check if this issue has been reported before?
Pretty sure I searched for it when I reported it. I would not have reported as a new bug if that search did not come up empty.
Just checked with the current Fresh 5.4.3. Created the table in about a second, still waiting for LO Writer to ungray.
Created attachment 137885 [details] Example file to test inserting The CPU burning is related to having Automatic spellchecking enabled (Tools menu). In 6.0, the CPU burning is noticeable, but only lasts for a few seconds. Test by going to Table - Insert - Rows and inserting the 104 before the 2nd row. Arch Linux 64-bit Version: 6.0.0.0.alpha1+ Build ID: 121303615054568c204def97872343d2014af4a0 CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on November 17th 2017
The amount of CPU Burning appears to be exponential in relation to the size of the table, Adding single rows with about 23 rows in the table results in about 6-7 minutes of CPU burning on this AMD Turion TL-60 with LO 5.1.6 under Ubuntu 16.04(32bit).
No repro with Version: 6.1.0.0.alpha0+ Build ID: b87fe45e8b087a315a65b92bf9c168b1e4c5cc00 CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-02-16_23:14:35 Locale: nl-NL (nl_NL); Calc: CL following the steps in comment 6
(In reply to Telesto from comment #8) > No repro with > Version: 6.1.0.0.alpha0+ > Build ID: b87fe45e8b087a315a65b92bf9c168b1e4c5cc00 > CPU threads: 4; OS: Windows 6.3; UI render: default; > TinderBox: Win-x86@42, Branch:master, Time: 2018-02-16_23:14:35 > Locale: nl-NL (nl_NL); Calc: CL > > following the steps in comment 6 Inserting 104 rows still results in the same CPU use. Arch Linux 64-bit Version: 6.1.0.0.alpha0+ Build ID: c902cbc7dc5294ab721a9aef3a152aa243d00011 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on February 17th 2018
(In reply to Buovjaga from comment #9) > Inserting 104 rows still results in the same CPU use. > > Arch Linux 64-bit > Version: 6.1.0.0.alpha0+ > Build ID: c902cbc7dc5294ab721a9aef3a152aa243d00011 > CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; > Locale: fi-FI (fi_FI.UTF-8); Calc: group > Built on February 17th 2018 Ok, I see. So no "unresponsive for at least 17 hours" or something like that. Only a small bump ;-)
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still a problem in 6.2.0.3-snap1. Checked on Linux 4.15 with default VCL gtk3
Addendum, the above re-test was with 64bit Ubuntu with an IronLake mobile cpu.
still 16.04 fresh install.
Still chugging away at it after 11mins.
It does seem pretty OK to me Version: 7.1.0.0.alpha0+ (x64) Build ID: e8b8e7be0b2ad693224cd94062a55610eb69df7e 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 Of course Skia backend.. no clue about GTK3/GEN/KDE
Yeah, it is only a very brief peak now. Arch Linux 64-bit Version: 7.1.0.0.alpha0+ Build ID: 4b7ee7bd61f78be60211cc72ba36da987191266e CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 7 September 2020