Description: After attempt to open a valid pdf file (it was printed in Foxit reader and can be opened successfully fith every program I could find) Libre Office draw (and calc too) hangs with 100% CPU. Steps to Reproduce: 1. Run Libre Office draw 2. Try to open attached file 3. Actual Results: It hangs with 100% CPU Expected Results: It opens and render a file Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Version: 6.0.0.3 Build ID: 64a0f66915f38c6217de274f0aa8e15618924765 CPU threads: 4; OS: Linux 4.9; UI render: default; VCL: kde4; Locale: ru-RU (ru_RU.UTF-8); Calc: group User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Created attachment 139389 [details] Test file
Confirmed. The pdfium Insert filter rather than pdfio Open filter (to Draw by default) handles the rotated table pages without issue.
File opens eventually; it's only slow (for me on Windows) Fast with: Version: 5.2.5.0.0+ Build ID: a4d4fbeb623013f6377b30711ceedb38ea4b49f8 CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-2, Time: 2016-12-24_14:43:55 Locale: nl-NL (nl_NL); Calc: CL a bit slower Versie: 5.3.5.2 Build ID: 50d9bf2b0a79cdb85a3814b592608037a682059d CPU-threads: 4; Besturingssysteem:Windows 6.2; UI-render: standaard; Layout Engine: new; Locale: nl-NL (nl_NL); Calc: group A lot slower with Version: 5.4.0.3 Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c CPU threads: 4; OS: Windows 6.2; UI render: default; Locale: nl-NL (nl_NL); Calc: CL and with Version: 6.1.0.0.alpha0+ Build ID: 80fb8d406ced47e6a2089f0c8ba5c103d2fec91f CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2018-01-15_05:18:42 Locale: nl-NL (nl_NL); Calc: CL
Bisected to author Miklos Vajna <vmiklos@collabora.co.uk> 2017-04-26 17:52:27 +0200 committer Miklos Vajna <vmiklos@collabora.co.uk> 2017-04-26 18:35:56 +0200 commit 1b471124df251011b0053900cb82ceb0f3d8be86 (patch) tree d2a6a2abc6c6d57b26b43d74a88ef1dd15293ec3 parent ad6515f48ced36ab9d10840aa60670fc41d25c6b (diff) tdf#107392 ODF import: fix z-order sorting of SVG images The problem was that in case the document has shapes where the order does not match the z-index order, so sorting is needed, then sorting failed to take the multi-image feature into account. E.g. SVG images have a PNG fallback, but at the end of the shape import the PNG fallback is removed, which means the "actual" (not the "wished") z-index of the shapes after the SVG image has to be adjusted. Without this happening SvxDrawPage::getByIndex() (or in case of Writer, SwTextBoxHelper::getByIndex()) will throw when the importer calls getByIndex(3) but we only have 3 shapes. This results in not honoring the z-index request of the remaining shapes. Regression from commit 44cfc7cb6533d827fd2d6e586d92c61d7d7f7a70 (re-base on ALv2 code. Includes (at least) relevant parts of:, 2012-10-09), from the
Adding CC to Miklos Vajna
Adding Cc: to Miklos Vajna
Dear Dmitry Yakimov, 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
This improved a lot in the 6.2 -> 6.3 timeframe. Oldest 6.3 is around 50s for me, newest 6.3 is rather in the 20s range. Reverse bisecting points out: commit bd44b3eef62f4325a189539d6ab1b90ca63cfc28 Author: Noel Grandin <noel.grandin@collabora.co.uk> Date: Wed Apr 24 13:40:59 2019 +0200 tdf#89522 PERF FILEOPEN xlsx, part 1 Inherit from tools::WeakBase non-virtually, so that we can use a static_cast in tools::WeakReference::get instead of a dynamic_cast. This takes the file-open time from 1m21 to 40s for me. Add a clang plugin to make sure we don't accidentally end up inheriting from tools::WeakBase more than once. Change-Id: I9c7c36403333f99094e1f9d8cce2ecd9200377f9 Reviewed-on: https://gerrit.libreoffice.org/71231 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Thanks Noel. :-) I guess we can close this, then.
These are my findings: in Version: 5.3.0.0.alpha1+ Build ID: 4136757b4e51c4e6f7cb4132c95538a7f831ef2c CPU Threads: 4; OS Version: Linux 4.15; UI Render: default; VCL: gtk3; Layout Engine: new; Locale: ca-ES (ca_ES.UTF-8); Calc: group it takes real 0m10,072s user 0m9,171s sys 0m0,250s in Version: 6.2.0.0.alpha1+ Build ID: a20a2d7e0d28658f2d9089da076961a599833a28 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 takes real 1m54,790s user 1m50,198s sys 0m0,787s and in Version: 6.4.0.0.alpha0+ Build ID: 850693273970be2662cce8f4d2710b3657a02f65 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 takes real 0m40,405s user 0m36,665s sys 0m0,444s so in master and 6.3 it's much better than 6.2, but not as good as it was in 5.4 ( 4 times slower for me ). I think it's fair to keep it open
OK, let's do that. So I profiled this with callgrind and as far as I see the next thing we could do is to improve the sdext/ code to produce flat ODF which has no replacement graphics, since it'll be just discarded on ODF import anyway. But that always worked like this, so then let's not call this a regression. Basically Noel already did what I would have done when it comes to fixing the perf regression. Thanks. (After all, first we want to be correct, and only then we want to be fast, right? :-) )
(In reply to Miklos Vajna from comment #10) > But that always worked like this, so then let's not call this a regression. > Basically Noel already did what I would have done when it comes to fixing > the perf regression. Thanks. > > (After all, first we want to be correct, and only then we want to be fast, > right? :-) ) A new bug report seems the smarter choice. It only causes trouble & confusion tracking the bug; IMHO
It's fine for me either way.
Bugs are very common in office working while the systems get heat turning on for many hours. The libre office was caught on the https://www.resumesservicesreviews.com/brooklyn-resume-studio-review/ draw hangs with the opening of file turned into pdf.
This seems pretty quick to me with current master (7.2) Could probably be closed.
(In reply to Noel Grandin from comment #14) > This seems pretty quick to me with current master (7.2) > > Could probably be closed. Yep, it opens within 5 seconds for me Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: f2389a70da606768a39ee599de6a5b24058734aa CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: zh-TW (en_US.UTF-8); UI: en-US Calc: threaded Closing as RESOLVED WORKSFORME for now. I'll check when it got fixed
Issue fixed by author Katarina Behrens <Katarina.Behrens@cib.de> 2019-07-01 18:20:02 +0200 committer Katarina Behrens <Katarina.Behrens@cib.de> 2019-10-25 16:27:04 +0200 commit a8b1699ca9c7e8c43eff79467451fd1fcb4fde9b (patch) tree 685f005a1b6c417c3b582d80dce51d0138970cff parent edcc3d66f9a107b8d9ffb3c5899e7863cf508484 (diff) speed-up shape import if shapes need z-order rearranging