inkscape crashes on document resize

[sachit]

When all the elements of the attached "crash-drawing.svg" are selected (ctrl-a) and the "resize document to selection" button in the "page properties" is clicked it crashes.

gdb output:

glibmm-ERROR **:
unhandled exception (type std::exception) in signal handler:
what: lib2geom exception: Non-contiguous path (2geom/path.cpp:88)

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff4481313 in g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
(gdb) quit

The image was created by copying all the elements (ctrl-a ctrl-c) from bad-display.svg and pasting into a new file. bad display was created in inkscape.

System: inkscape 0.48 on ubuntu 64 bit

[su_v (suv-lp)]

Crash reproduced with Inkscape 0.48.2 on OS X 10.7.2 when resizing the page to seclection (Ctrl+A)
Current trunk (Inkscape 0.48+devel r10992) already crashes when loading the file.

Probably related to the same object which causes rendering of the file to stop in rsvg-view and Squiggle (Batik 1.7), as reported in bug #935171 (see comment #7).

[su_v (suv-lp)]

full backtrace (r10992 on OS X 10.7.2 64bit)

[su_v (suv-lp)]

No crash in Inkscape 0.48.2 and 0.48+devel r10992 after deleting this object:

    <path
       style="fill:none;stroke:#000000;stroke-width:nan;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Lend)"
       d="m 105.71421,115.82283 0,159.99998"
       id="path4480"
       inkscape:connector-curvature="0" />

[jazzynico (jazzynico)]

Replacing stroke-width:nan; with stroke-width:8; (or any other number) fixes the crash.

@staticd - Did you edit the file manually with the XML editor or an external tool? It would be interesting to understand how the "nan" value was introduced in the document.

[su_v (suv-lp)]

@JazzyNico - the object was created by pasting the path triggering bug #935171 into a new document (-> the former preserved transform attribute gets applied to the path data and adjusts the stroke width as well).

Original path (creating errors in batik, and cairo):

    <path
       style="fill:none;stroke:#000000;stroke-width:8;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Lend)"
       d="M 600,612.36218 360,732.36217"
       id="path4480"
       inkscape:connector-curvature="0"
       transform="matrix(0,0,0,1.3333335,946.05418,64.48649)" />

Same path with flattened transform in new document (causing inkscape to crash):

    <path
       style="fill:none;stroke:#000000;stroke-width:nan;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Lend)"
       d="m 105.71421,115.82283 0,159.99998"
       id="path4480"
       inkscape:connector-curvature="0" />

[su_v (suv-lp)]

To reproduce the 'nan' stroke width:

1) launch Inkscape 0.48.2
2) open the file 'bad_display.svg' from comment #1
3) select the path with arrow just below the word 'Fusion'
4) press <TAB> once to select the "odd" path
   (path is only visible in outline mode, no selection handles are displayed)
5) invert select and delete the rest
6) press <TAB> again to select the remaining path
7) nudge with arrow keys to flatten transform (watch stroke width in style indicator (status bar))

Optional:
8) save under different file name
9) open this file in current trunk
-> same crash

[Johan Engelen (johanengelen)]

So the 'nan' is fixed, and only the crash is still in trunk?

[Johan Engelen (johanengelen)]

don't know what to do with ill-defined stroke widths. I've fixed the crash by exiting the stroke-width setting function (r10995). Effectively, for non-finite stroke width values, Inkscape pretends no stroke width has been set (and defaults to 1px).

[su_v (suv-lp)]

> So the 'nan' is fixed, and only the crash is still in trunk?

AFAICT yes - with current trunk, the conversion of the stroke width to NaN does not occur when flattening the transform of path "path4480" in 'bad_display.svg' (e.g. by nudging it with the arrow keys).

Exporting the file 'bad_display.svg' (as is) with current trunk (cairo 1.10.2 as well as 1.11.2) to PDF/PS/Cairo PNG however still stops processing the file after the object with id "path4480" (see also bug #935171 (based on the same file), bug #534679 (with earlier reported examples) and comment #19 there for a summary).

Note: I do not know which steps in Inkscape 0.48.2 created the object in the first place (resulting in a path which triggers a technical error in other user agents), nor if this also could happen in current trunk (this aspect might probably better be tracked in bug #935171).

[su_v (suv-lp)]

> AFAICT yes - (…)

My tests had been based on trunk r10990 (cairo 1.11.2) and r10993 (cairo 1.10.2) - i.e. without the most recent revision r10995 which was committed while I was writing the reply to comment #9.