Situation is a lot like bug #53653 Try to open large (7 MB) excel-formatted large spreadsheet, hangs for a long time, maybe permanently. Impossible to stop or kill process - to get rid of the hanging spreadsheet, a reboot is necessary. This file causes this problem: https://dl.dropbox.com/u/17907527/R1b-L21_Haplotypes.zip
[Reproducible] with "LibreOffice 3.6.1.1 German UI/Locale [Build-ID: 4db6344] on German WIN7 Home Premium (64bit) It takes a minute or so until progress bar reaches 80%, then LibOO stops responding. That's some better than AOOo 3.4, what stops responding ag 20% porgress bar, but mich worse than MS Excel Viewer, what opens the document within 10 seconds. Parallel installation of Master "LOdev 3.7.0.0.alpha0+ - WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 6900781]" (tinderbox: 2008R2@20, pull time 2012-08-14 09:27:23) opens the document within several minutes. I will still do some additional tests. @michael helm: Did you ever see that working better with LibO or OOo?
Also 3.6.6.1 will open the document after 1/2 h or so. There is some excessive conditional formatting in the document what might be part of the problem? I did not test this. I doubt that for this issue will be any action for 3.5, so Performance issue for 3.6 @Spreadsheet Team Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug (and remove others in team from CC)
oO (the newest one - 3.4.1) is at least as bad - as far as I can tell it never managed to open the document completely & left the spreadsheet application in a weird non functional state. I probably should report that to Apache, too.
Created attachment 68145 [details] bts + console logs on master On pc Debian x86-64 with master sources updated yesterday, I've got a freeze (or at least, i can't load the file after more than a minute perhaps 2). I attached several bts, after the third I had a popup dialog about macro security. I attached too console logs.
The same problem remains with LO 4.0.0.1. (on Windows 7 and Ubuntu 64bit).
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team
The same problem remains with LO 4.0.5 and LO 4.1.2 on Windows 7 64-bit.
** 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 (4.4.1 or later) 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 your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-18
The same problem remains with LO 4.4 both on Windows 7 and Ubuntu 64-bit. Inherited from OO. According to https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg marked as Major-High.
Migrating Whiteboard tags to Keywords: (perf)
On git master, it takes 2 minutes to load this document on my desktop computer. Still way to long, but at least it finishes. A significant part of the time is spend in getting locale details in order to do cell number formatting. The result of LocaleDataImpl::getAllFormats(lang) is supposed to be cached, but that seems not to happen. I have some patches fixing this, reducing the load time to 1 minute. When that is posted, we'll see how to go from there.
Maarten Bosmans committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=110183572bfe9da0020b4c506d4b458bf69b1e85 tdf#53698: Add a NumberFormatMapper member to SvNumberformatScan It will be available in 5.3.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.
Maarten Bosmans committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=450a2fd5e2dafd1a0c08e73ef85db978f6b1a927 tdf#53698: Cache more than 1 item in NumberFormatCodeMapper It will be available in 5.3.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.
Hello Maarten, Is this bug already fixed? If so, could you please close it as RESOLVED FIXED?
Hi michael helm, is it possible to re-upload the file? https://dl.dropbox.com/u/17907527/R1b-L21_Haplotypes.zip no longer works...
Created attachment 134061 [details] Test XLSM Doesn't look good to me, please see if it's acceptable
in Version: 5.5.0.0.alpha0+ Build ID: 6ab249ea6aecef5d3f35d624622a368061cad9c3 CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group it takes to open real 1m58.074s user 2m1.104s sys 0m1.628s while in Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e I killed it after real 12m11.521s user 12m11.028s sys 0m0.884s
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
I'm having a very similar issue. I am trying to open a 16MB large XLSM file (https://www.dropbox.com/s/m4m1nurerbg0dpf/DS-NKh-Sentence%20Maker.zip?dl=0). The progress bar goes up to about 80% before the process hangs. Task manager shows me LibreOffice is using 25% of the CPU and 1.2GB of RAM, but it doesn't seem to be able to finish the task.
PS : Using LO 5.4.2.2
** 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
Dear michael helm, 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 https://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
LO opened it about for 1 minute in Version: 7.2.0.0.alpha0+ (x64) Build ID: ad9e04321df25824d2288a2ef1f4275f070f1cf7 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: CL Xisco, can you retest it? I mean is it still a bug? Excel opens the file about for 20 sec for me
it takes real 0m43,637s user 0m44,475s sys 0m2,125s in Version: 7.2.0.0.alpha0+ Build ID: 2c9708cbb870483a8a1c93d722085be5f789d234 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded and Version: 7.0.5.0.0+ Build ID: 7893e24c82c97de9c066f6e09df0ac107a6d97dd CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded I guess we can close this as RESOLVED WORKSFORME
OO 3.3 very long LO 4.3 m too long as in Comment 17 5.4 m real 4m45,608s user 4m55,664s sys 0m4,217s 6.2 m real 4m7,726s user 4m11,673s sys 0m6,010s 6.3 m real 1m23,676s user 1m30,713s sys 0m3,867s 6.4 m real 1m37,252s user 1m43,380s sys 0m4,039s 7.0 m real 1m50,430s user 1m36,137s sys 0m2,961s 7.3 m real 1m8,606s user 1m11,307s sys 0m1,667s LO improved in LO 6.3.
I wanted to find a commit, but my 6.2 master is NOK and 6.3 oldest is OK.
(In reply to Timur from comment #26) > I wanted to find a commit, but my 6.2 master is NOK and 6.3 oldest is OK. Buovjaga, please see this.
Bibisected the fix to https://git.libreoffice.org/core/commit/0702541b3d4661846dccde26efa9c2fb5ed65f35 tdf#126663: optimize style list display in sidebar Julien is in Cc here, so let's thank him of this 2019 fix :)