Dasharray on very long lines uses lots of memory

[Bug Importer]

Inkscape failed to display my file
--------------------------------------
terminate called after throwing an instance of 'std::bad_alloc'
  what(): std::bad_alloc

Emergency save activated!
Emergency save completed. Inkscape will close now.
If you can reproduce this crash, please file a bug at www.inkscape.org
with a detailed description of the steps leading to the crash, so we can
fix it.
---------------------------------------
The file is attached
Yours
Ilia Chibrikin <email address hidden>

[Peter Moulder (pjrm)]

Originator: NO

Seems to be a case of running out of memory. Suggested approach for
diagnosis would be to try removing bits from the file to see if a much
smaller file can still cause out-of-memory. The SVG file has 1887 lines,
and maybe 1411 elements, and the inkscape process uses more than 1GB of
memory (I killed the process after it got to about 1.5GB), so averaging
about 1M per element, which seems excessive. I don't see anything
particularly harmful in the SVG file from a brief look. There are no URLs
apparent (i.e. search for `#' finds no matches), which rules out the most
obvious way there could be an infinite loop.

c$ sed 's,</[^<>]*>,,g' < ~/svg/crash-J1.svg |grep '<'|tr \ \\n|grep
'<'|sort|uniq -c
      1 <!DOCTYPE
      1 <?xml
    856 <circle
    235 <g
     80 <line
      1 <path
      1 <svg
    236 <text

*looks at the path element*

Ah, got it: creating an SVG file containing just the path element from the
file is enough to trigger huge memory use. Further reducing the example,
it appears that it's the combination of dasharray and a very long line: the
following also uses lots of memory:

  <svg>
    <path d="M13542155 7565968 L751 516" style="fill:none;
stroke-dasharray:5 3;stroke:#000"/>
  </svg>

whereas either removing the stroke-dasharray property or changing the
initial moveto to be closer to the destination is enough to make inkscape
render the document fine. (True of both SVN head and 0.44.1; haven't tried
0.45, though I suppose it'll be the same.)

I suspect that the renderer is converting the long dashed into about
2million line segments as an intermediate step.

I'm inclined to mark this bug as WONTFIX or move it to an RFE. It's not
too surprising that a diagram containing in effect about 2million line
segments takes a lot of memory to render, even if it's easy to think of
optimizations that would make it use less memory. How common are such
cases? I wouldn't be surprised if the huge coordinates in this example
file are actually a bug in the process that generated this file. Certainly
these coordinates are well outside what SVG Tiny is expected to handle
(±32767.99999, from memory).

Comments?

[vonHalenbach (lustik)]

This means to me, that inkscape should find out, how many memory is savely available for use and limit the size of the area to a sensible amount to prevent such cases of crashing, because inkscape allocates too much memory. Lines don't need to have an infinite length.

[Andreas Becker (abecker)]

Perhaps using cairo reduces memory usage. The implementation is *very* simple (http://zetcode.com/tutorials/cairographicstutorial/basicdrawing/), so moving to cairo could pay off more than optimizing livarot.

[ScislaC (scislac)]

We've already switched to cairo and it seems to use less than 80megs of ram here... I'd say it's fixed in trunk. I'm going to close this as fix committed, if you feel this was closed in error feel free to re-open and explain why.