Created attachment 126372 [details] SVG that will cause LibreOffice to hang Attempting to import the attached SVG causes all Libre Office components I've tried (Writer, Draw and Impress) to hang, consuming 100% cpu. This SVG was generated from: 1) A Grace (http://plasma-gate.weizmann.ac.il/Grace/) graph that was saved as a PDF 2) Opening that PDF with Inkscape and saving it as an SVG To reproduce: 1) Open {Writer,Impress,Draw,...} 2) Select "Insert Image" 3) Select the attached SVG That's it - Libre Office then consumes 100% cpu and doesn't leave the file picker dialog. Using Ubuntu 16.04 on x86_64.
Confirmed with v5.1.5.1 under windows 7 x64. Confirmed with v5.2.0.3 under ubuntu 16.04 x64.
The old filter does open it into Draw, but with terrible font metrics--text extends out of the canvas. But the newer svgio filter chokes on it--so maybe another issue with fill pattern as we've seen before. The SVG opens quickly into Inkscape and Firefox, and on save from Inkscape as "simple SVG" there is no improvement in attempting to insert the image (i.e. svgio filter) still chokes. On Windows 10 Pro 64-bit en-US with Version: 5.3.0.0.alpha0+ Build ID: 9dc3356f1499a2b90078be86ca7470eb2e96aba8 CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; TinderBox: Win-x86@39, Branch:master, Time: 2016-07-21_23:52:45 Locale: en-US (en_US); Calc: CL
The hang started between 3.6.0.4 and 4.0.0.3, so that part is a regression. However, the SVG never looked correct, so I'm not sure comparing the two versions would get anywhere. In some releases it looked a bit better, in others worse (the text with terrible font metrics is a new addition in 5.2).
Created attachment 127932 [details] simplifier sample I've investigated this issue a bit and the problem comes when the element pattern is something like patternTransform="scale(0.00163399,0.00163399)". However, it doesn't hang when it's like patternTransform="rotate(35)". Attaching a simplifier sample
it looks like the hang was introduced in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=d85fd8a85501547d5bb87822d2589a07aed7f2d6..d38a2e3ea04d354492df18aa16d2304babe87dfb
*** Bug 58420 has been marked as a duplicate of this bug. ***
this seems to be working on current master
Still not fixed with Version: 6.0.4.2 (x64) Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf CPU threads: 3; OS: Windows 6.1; UI render: default Could anyone backport it ?
Not fixed for me (LO hangs), tested with latest commit of bibisect-win32-6.1 as of today (ac27f4e7abf5339f71d4f5f3fc09a13b25669fe4) in Windows 7.
Not fixed for me with Version: 6.1.0.0.alpha1+ (x64) Build-ID: 439f17c5cf43b38092b1b834bb006420220262e1 CPU-Threads: 8; BS: Windows 10.0; UI-Render: GL; Gebietsschema: de-DE (de_DE); Calc: CL The problem is the patternTransform attribute in the <pattern> element. If I set the scaling factor to 0.163399, there are no problems. With scaling factor 0.0163399 I get high computer workload, but in the end it is rendered and on high zoom the circles are visible. factor 0.163399 means about 30×30=900 circles to be rendered. factor 0.0163399 means about 300×300=90000 circles to be rendered. factor 0.00163399 as in the attached "simplifier sample" file means about 3000×3000=9000000 circles to be rendered. I think, there need to be a cut, so that if the to be drawn circle becomes smaller then a threshold, it is no longer drawn as circle. Ersatz might be solid filling with a color with transparency, which considers the percentage of the filled area. I cannot confirm, that it worked before version 3.6. In version LibreOffice 3.5.1.2 Build ID: dc9775d-05ecbee-0851ad3-1586698-727bf66 the graphic is not rendered at all.
Dear librereporter, 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
Repro Lo 6.5+
Repro Lo 7.0.0.0 beta2
(In reply to Regina Henschel from comment #11) > > I think, there need to be a cut, so that if the to be drawn circle becomes > smaller then a threshold, it is no longer drawn as circle. Ersatz might be That is a reasonable idea - the other option is to teach the renderers to handle PatternFillPrimitive2D without decomposing it.
Made a short check what's going on. Generic sys-dep renderers would be ideal (and were always the target after cont'ing the changes) but would not help too much here. The PatternFillPrimitive2D already does a decent, discrete (res- and target dependent) buffered decomposition. Did that once for a similar case - the pattern is tran'd to a bitmap and embedded in a stack of matrices to reflect the fill (done based on discrete pixel size of pattern back-transformed to have no gaps in pattern :) important). In this case the range and size of the pattern derived/imported from the SVG lead to creation of 2mio sub-primitives - argh! Either there is an error in this file or we need to limit amount of decomp parts anyways due to mem overrun attacks... Just my 2ct
Comment to comment 11: Already correct to go, just wanted to mention that what I saw in dbg with unchanged scale the pattern gets a view-dep size of 16x16 pixels, so not sure if that should be reduced more. Maybe a mix of limiting scaling and enlarging BM by repeating would be good. In this case e.g using 10x10 patterns in a bitmap going to 160x160 and reducing the scale by 1/10th...
And one last: a direct sys-dep renderer could create the 16x16 pattern but could just paint it, even when 16mio times - would not need to create matrix and primitive instances. Still, that does not touch the basic problem of just too small pattern elements...
Repro Lo 7.1.3.2 win64
Still reproducible in Version: 7.2.0.0.alpha1+ / LibreOffice Community Build ID: c781776f3c79bbe3175b1452d26c79ebb931a500 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Noel, I thought you might be interested in this issue!!
still, repro in Version: 7.2.0.2 (x64) / LibreOffice Community Build ID: 614be4f5c67816389257027dc5e56c801a547089 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3cbe3a0259bea4dec70e72191ec3c03441926a07 tdf#101083 speed up SVG rendering with pattern fill It will be available in 7.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Now it is instant Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: eae0636311d3a1b3a1af58a3e4df686b55afa3fa CPU threads: 8; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded
SVG-import of examples hangs in 7.3.4.2 Version: 7.3.4.2 (x64) / LibreOffice Community Build ID: 728fec16bd5f605073805c3c9e7c4212a0120dc5 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL
(In reply to paulystefan from comment #25) > SVG-import of examples hangs in 7.3.4.2 Yep, but that's a different issue, so I created bug 149592