Bug 101083 - Insert SVG with too small scaling causes LibreOffice to hang, consuming 100% cpu
Summary: Insert SVG with too small scaling causes LibreOffice to hang, consuming 100% cpu
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All All
: medium major
Assignee: Not Assigned
URL:
Whiteboard: target:7.3.0
Keywords: bibisected, filter:svg, perf
: 58420 (view as bug list)
Depends on:
Blocks: SVG-Import
  Show dependency treegraph
 
Reported: 2016-07-23 10:40 UTC by librereporter
Modified: 2021-09-02 09:31 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
SVG that will cause LibreOffice to hang (230.40 KB, image/svg+xml)
2016-07-23 10:40 UTC, librereporter
Details
simplifier sample (572 bytes, image/svg+xml)
2016-10-10 19:12 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description librereporter 2016-07-23 10:40:28 UTC
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.
Comment 1 MM 2016-07-23 11:37:11 UTC
Confirmed with v5.1.5.1 under windows 7 x64.
Confirmed with v5.2.0.3 under ubuntu 16.04 x64.
Comment 2 V Stuart Foote 2016-07-23 16:15:07 UTC
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
Comment 3 Aron Budea 2016-08-06 04:06:57 UTC
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).
Comment 4 Xisco Faulí 2016-10-10 19:12:26 UTC
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
Comment 6 Xisco Faulí 2017-09-14 10:41:08 UTC
*** Bug 58420 has been marked as a duplicate of this bug. ***
Comment 7 Xisco Faulí 2017-09-14 10:44:41 UTC Comment hidden (obsolete)
Comment 8 Noel Grandin 2018-03-26 11:30:26 UTC Comment hidden (obsolete)
Comment 9 MM 2018-05-12 11:24:07 UTC Comment hidden (obsolete)
Comment 10 Aron Budea 2018-05-13 13:33:13 UTC
Not fixed for me (LO hangs), tested with latest commit of bibisect-win32-6.1 as of today (ac27f4e7abf5339f71d4f5f3fc09a13b25669fe4) in Windows 7.
Comment 11 Regina Henschel 2018-05-13 16:54:46 UTC
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.
Comment 12 QA Administrators 2019-05-14 02:58:29 UTC Comment hidden (obsolete)
Comment 13 Timur 2019-11-22 14:53:00 UTC Comment hidden (obsolete)
Comment 14 paulystefan 2020-06-20 20:32:22 UTC Comment hidden (obsolete)
Comment 15 paulystefan 2020-06-20 20:32:34 UTC Comment hidden (obsolete)
Comment 16 Noel Grandin 2021-01-30 11:22:42 UTC
(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.
Comment 17 Armin Le Grand 2021-02-03 09:47:28 UTC
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 18 Armin Le Grand 2021-02-03 09:53:10 UTC
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...
Comment 19 Armin Le Grand 2021-02-03 09:54:59 UTC
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...
Comment 20 paulystefan 2021-05-17 14:29:15 UTC Comment hidden (obsolete)
Comment 21 Xisco Faulí 2021-05-17 16:03:03 UTC Comment hidden (obsolete)
Comment 22 paulystefan 2021-08-06 00:53:11 UTC
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
Comment 23 Commit Notification 2021-08-27 06:49:12 UTC
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.
Comment 24 Buovjaga 2021-09-02 09:31:20 UTC
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