inkscape crashes on document resize

Bug #935157 reported by sachit on 2012-02-18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Johan Engelen

Bug Description

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/
(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

sachit (staticd-growthecommons) wrote :
sachit (staticd-growthecommons) wrote :
su_v (suv-lp) wrote :

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).

tags: added: crash
su_v (suv-lp) wrote :

full backtrace (r10992 on OS X 10.7.2 64bit)

Changed in inkscape:
importance: Undecided → High
status: New → Confirmed
su_v (suv-lp) wrote :

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

       d="m 105.71421,115.82283 0,159.99998"
       inkscape:connector-curvature="0" />

jazzynico (jazzynico) wrote :

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) wrote :

@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):

       d="M 600,612.36218 360,732.36217"
       transform="matrix(0,0,0,1.3333335,946.05418,64.48649)" />

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

       d="m 105.71421,115.82283 0,159.99998"
       inkscape:connector-curvature="0" />

su_v (suv-lp) wrote :

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))

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

Johan Engelen (johanengelen) wrote :

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

Johan Engelen (johanengelen) wrote :

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).

Changed in inkscape:
assignee: nobody → Johan Engelen (johanengelen)
milestone: none → 0.49
status: Confirmed → Fix Committed
su_v (suv-lp) wrote :

> 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) wrote :

> 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.

Bryce Harrington (bryce) on 2015-02-21
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers