Created attachment 119312 [details] gdb information LO 4.4.5.2 Infinite loop (100% CPU usage) trying to open Excel file Cannot provide the Excel as it is confidential but may be able to reduce it to a minimum test case attaching the gdb diagnose information I tool
Please attach anonymized Excel file (xlsx, xls?) Please try with the current LO master, for example http://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@70-TDF/current/.
Infinite loop does not happen with lastest LO5 alpha build. I reduced it to an anonymised minimum test case that I am attaching.
Created attachment 119712 [details] minimum test case
(In reply to c.kirbach from comment #2) > Infinite loop does not happen with latest LO5 alpha build. It doesn't happen with master, LO 5.1+, although it's rather slow to open. It opens even with 5.0.2.2, but after a "very" long time, so I wouldn't say it's infinite loop. It was some recent regression in terms of terribly slow opening. Looks like something is fixed, and future releases 5.0.3 and 4.4.6 should be checked for backport. I think this bug may be closed as "WorksForMe" but another one should be open for poor performance with the opening. It's a regression from LO 3.4. LO 5.1+ took 112 sec in Windows with i7 processor. OO 3.3 and LO 3.3.4 took "only" 27 seconds to open. Or this bug may be changed to "Fileopen: performance regression for xlsx with chart"
Renaming as suggested by you. It doesn't happen with master, LO 5.1+, although it's rather slow to open. It opens even with 5.0.2.2, but after a "very" long time. It was some recent regression in terms of terribly slow opening. Looks like something is fixed, and future releases 5.0.3 and 4.4.6 should be checked for backport.
Please don't forget to tag performance problems as they can be easily missed.
(In reply to c.kirbach from comment #5) > Renaming as suggested by you. > > > It doesn't happen with master, LO 5.1+, although it's rather slow to open. > It opens even with 5.0.2.2, but after a "very" long time. It was some recent > regression in terms of terribly slow opening. > Looks like something is fixed, and future releases 5.0.3 and 4.4.6 should be > checked for backport. Performance improvements are nearly never backported.
Adding keyword 'bibisectRequest'
** 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 on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170929
I retested with LO 5.4.4 and the former behaviour was significantly improved. Opening the test file takes about 25 seconds. I think we could do even better, but as the worst has been resolved. I will leave it for others to decide whether it is worth to keep this case open. Thank you for your support in this issue.
It takes 55 sec for me to open in LO 6.1+ and just 5 sec in MSO. Although it's also slow in MSO ang gives warning "Max number of data labels is 1.000. Some labels will be omitted from the chart". But, there also a dump on fileopen that can be seen with procdump: SYMBOL_NAME: svllo!SfxBroadcaster::RemoveListener+16 IMAGE_NAME: svllo.dll FAILURE_ID_HASH_STRING: um:status_breakpoint_80000003_svllo.dll!sfxbroadcaster::removelistener So I 'll set back to New. (BTW: if it worked it'd be WorksForMe and not FIXED which is used if fix commit is known)
Noel Grandin committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=20083840700518d8c0ec314974249254eb859de7 tdf#94792 performance regression for xlsx with chart with >1000 data labels It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Note that there is no point in comparing LO to MSO if MSO is going to throw most of the data away.
Noel: a gain of 30% is a lot! Did you plan some backports (at least on 6.1)
There's again dump with master but different one: MODULE_NAME: heap_corruption DEBUG_FLR_IMAGE_TIMESTAMP: 0 STACK_COMMAND: dt ntdll!LdrpLastDllInitializer BaseDllName ; dt ntdll!LdrpFailureData ; ** Pseudo Context ** ; kb FAILURE_BUCKET_ID: HEAP_CORRUPTION_80000003_heap_corruption!heap_corruption Please comment should this one be reopened or new one created?
@timur that's different please open new bug @julien I will backport to 6.1
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-6-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=378f15a48bcb9fc9676644c20541a943efcd5565&h=libreoffice-6-1 tdf#94792 performance regression for xlsx with chart with >1000 data labels It will be available in 6.1.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.