I have a complex "A0" size document (total size 1.8MiB) that now refuses to open under draw. I left it opening over night, it used 25 hours of CPU time (pegging one of 8 cores at 100% for the whole time) and ultimately XFCE crashed. The initial view of the document comes up in a normal amount of time time, but it never renders the thumbnails of additional pages, no Libre Office component is responsive and while the window decorations redraw, menus don't open, etc.; the LibreOffice suite is completely non-responsive. Clicking on the close window eventually triggers the unresponsive application warning and it can be force-quit. Version: 5.0.3.2 Build ID: 1:5.0.3~rc2-0ubuntu1~trusty2 Locale: en-US (en_US.UTF-8) Kernel: 3.19.0-32-generic x86_64 (64 bit) Desktop: Xfce 4.12.2 Distro: Linux Mint 17.3 Rosa I also have a VM of Win 7 ultimate/SP1 running under VMWare workstation and LO Version: 4.3.5.2 Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5 running on that. The same document opens normally on that version of LO. It takes about 3 seconds to open the initial view and another 10 seconds or so to render 5 thumbnails of other views. In attempting to fix the failure to load, I've tried allocating more memory to the graphics cache (no change) and turned off OpenCL and Java (no change). (below is after having made the above changes and waiting approximately 40 minutes for the document to open) 4 6704 user 20 0 2184M 1255M 108M R 100. 3.9 37:14.70 /usr/lib/libreoffice/program/soffice.bin --draw --splash-pipe=5 5.0.3.2 seems to be current in the repositories. I'm happy to try a later release/5.2 beta if there's any reason to think a fix has been integrated. I don't want to update the Windows copy to current - even if the VM is very slow compared to the host, at least it gives me access to the drawing. 4 pages of complex A0 size drawings opened slowly, but adding a 5th changed a 10-15 minute load time to "forever". Breaking apart the drawings using the windows version, I can open single pages again. There seems to be an exponential increase in "thumbnail render time" with the number of A0 pages in the entire drawing.
We need the document to test. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the document. To try with the bleeding edge: http://dev-builds.libreoffice.org/daily/master/Win-x86_64@62-TDF/current/ http://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@70-TDF/current/ https://wiki.documentfoundation.org/Installing_in_parallel
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 INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/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 MassPing-NeedInfo-Ping-20161207
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-20170131
Created attachment 133623 [details] This is a demo document with a lot of objects on an A0 page that is very slow.
Can't confirm with 5.1 and master. Slow but similar both in Lin/Win to open (in a minute or so) and work, but opens not in hours. Since in took long to get a file, please test now with current LO versions or those that you have. I'm suggesting that you: - get http://tdf.io/siguiexe to easily get and run "parallel" LO in Windows (extract without installation) and - run different extracted versions and architectures (32-bit or 64-bit) related to this bug in order to test In Linux you can use Bash Script from http://pastebin.com/L6SFSYFR (just run /bin/LO-extract.sh) to Extract Parallel LO (no installation) from downloaded and unzipped LO folder with DEBS. Or install latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ or add LO PPA to install. I don't know why Ubuntu doesn't upgrade to x.y.last for stable branch. Personally, I'm using Still in production, it means version x.y.last.
Created attachment 133626 [details] Callgrind output from 5.5 master Arch Linux 64-bit, KDE Plasma 5 Version: 5.5.0.0.alpha0+ Build ID: e60529fdfe0502f64e3c975f71539b28146943e8 CPU threads: 8; OS: Linux 4.10; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on May 26th 2017
Well it seems to be faster in: Win 10 Version: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: fi_FI Arch Linux 64-bit Version 3.6.7.2 (Build ID: e183d5b) As I took a callgrind, let's set to NEW so we will lure someone to analyse it. Apparently the document is different from the one talked about in the description as it only has 1 page.
Yeah, this attachment is different because the one i was working with is confidential, unfortunately. I tried to create a new on that causes the same problems. I ran into massive delays opening more than 2 drawings of this size at the same time. I could more or less work by opening one at a time. I tried to create a multi-page document - the equivalent of copying the page in this document a few times and that's when I needed to recover it using version 4.x on Windows, which worked. I have VMs with latest and 4.X on Linux and can create the same on Windows for testing.
I can install parallel versions and test on the proprietary drawings. I checked out https://wiki.documentfoundation.org/QA/Testing/Subsequenttests but it isn't clear those tests can be run document specific. There are two manifestations of the same issue that might be testable to provide reproducible statistics: The time between initiating a document open and when that document is editable. The time between making a modification to the drawing and when the drawing is again editable (and the page iconifications update) The former is probably the most repeatable to test, but I'm not sure how to objectively time it (human observation and manual timing would seem to introduce too many opportunities for error). -David
(In reply to Gessel from comment #9) > I can install parallel versions and test on the proprietary drawings. I > checked out https://wiki.documentfoundation.org/QA/Testing/Subsequenttests > but it isn't clear those tests can be run document specific. That page is talking about automated tests that developers have defined using C++ or Java. To time a document open, you could use a special environment variable. So in a terminal you would give these commands: export OOO_EXIT_POST_STARTUP=1 time soffice document.odg When using parallel installs, point the soffice command to whichever specific path you want.
Thanks - i'll give it a try and post results by version.
** 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
Version: 6.2.2.2 does not seem to be affected under Mint 19.1 I think this can be closed.
Yeah, it's pretty fast: real 0m21,351s user 0m12,452s sys 0m2,067s Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: 9852f09b467e3c7f8058b931010b91f447905051 CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 27 March 2019