Not eggbot specific, but extremely long paths crash Inkscape?

[GoogleCodeExporter]

We have seen observed on more than one computer that using extremely long 
paths, such as the computational output from TSP art programs, can crash 
Inkscape, resulting in potential loss of data.  

The crash typically occurs when the Eggbot Control extension window is closed 
after performing complex plots.  As the operation of that dialog box is handled 
fully by Inkscape (not by the extension), it would indicate that the actual 
error is internal to Inkscape, or perhaps its handling of extensions. Using the 
same paths, we were able to cause separate crashes with some of the standard 
(built-in) extensions, which confirms that this issue is not eggbot specific. 

The fact that the crashes are not caused by the Eggbot extension is a mixed 
blessing. While it's nice to find that the fatal flaw is elsewhere, it is also 
the case that it's less easy for us to debug and fix.  If you see an error like 
this, please report it here, so that we can compile useful information towards 
a bug report for the Inkscape team.

First data point:  We have observed this problem on more than one 
recent-vintage Windows computer. Both had reasonably fast processors and 
seemingly ample RAM.

Original issue reported on code.google.com by windell@oskay.net on 4 Oct 2010 at 11:41

[GoogleCodeExporter]

If invalid XML gets fed back to Inkscape when an extension process shuts down, 
Inkscape will/may abort and shutdown.  (I've seen this as I'm debugging 
extensions.)  So, I'm wondering if occasionally that generator exception 
associated with the older eggbot_scanwin32.py code triggered its exception as 
the extension was winding down and whispering sweet nothings back to Inkscape.  
Inkscape took offense over the interrupted missive and decided to go play 
elsewhere.  Just a theory.

Original comment by newman.d...@gmail.com on 18 Oct 2010 at 8:22

[GoogleCodeExporter]

My intuition is that invalid XML is not the issue. 

When you hit 'Apply,' the extension begins to execute its python code, and 
Inkscape passes the SVG (XML) to the extension.  When the extension finishes 
executing-- that is, when the python code finishes --the SVG is returned to 
Inkscape, and then user control is restored to the GUI.  My experience with 
other extensions (ones that visibly modify the drawing) confirm this, since the 
drawing (and thus the SVG) can clearly be updated before the extension window 
is closed.  If there were a problem with the XML, I'd expect Inkscape to throw 
an error or crash when the extension executes, not *after* it has finished 
executing when you close the window.

We should be able to test that, by intentionally returning invalid XML to see 
how Inkscape reacts.

Also, I've been able to cause similar crashes with other extensions, with the 
same large files.  Whatever the issue is, it does not seem to be 
Eggbot-specific.

Original comment by windell@oskay.net on 18 Oct 2010 at 9:01

[GoogleCodeExporter]

The issue of long path data, or even long lines in SVG is very much not 
Inkscape specific. The SVG spec encourages lines to be kept to a reasonable 
length in path data, and rewriting the specific extensions to do so is probably 
the best path available. A simple method is to put a newline in-between every 
path segment, (for example after every C, S, L or M)

FYI: "Path data can contain newline characters and thus can be broken up into 
multiple lines to improve readability. Because of line length limitations with 
certain related tools, it is recommended that SVG generators split long path 
data strings across multiple lines, with each line not exceeding 255 
characters. Also note that newline characters are only allowed at certain 
places within path data."
http://www.w3.org/TR/SVG/paths.html

Original comment by cannon...@gmail.com on 12 Mar 2012 at 1:14

[GoogleCodeExporter]

Original comment by windell@oskay.net on 15 Dec 2014 at 9:44

• Changed state: WontFix