Inkscape

crash when scaling a circle, document units = 'm'

Bug #1309225 reported by Alvin Penner on 2014-04-17

This bug affects 2 people

Affects		Status	Importance	Assigned to	Milestone
	Inkscape	Fix Released	High	Alvin Penner	Inkscape 0.91 "0.91"
	lib2geom	Fix Committed	Undecided	Unassigned

Bug Description

this is a re-issue of a bug previously noted in Bug 1244861, comment 5.

- Windows XP, Inkscape 13288
- in Document Properties, set default document units to 'm'.
- draw a circle, set the diameter to 0.007 m.
- execute Path->Object to Path, to convert it to arcs.
- save as circle007.svg, attached here
- zoom in, to about 500%
- while holding down Ctrl, grab a corner and decrease radius slightly
- when the diameter is about .006 or .005, note that the circle becomes a 'diamond' or 'square', after releasing the mouse
- while holding down Ctrl, grab a corner and try to increase the radius again
- get a crash with the following console output:

terminate called after throwing an instance of 'Geom::ContinuityError'
what(): lib2geom exception: Non-contiguous path (src/2geom/path.cpp:386)

(the crash is easy to reproduce, the specific console message does not always appear, maybe shows up half the time)

Tags:

Related branches

lp:~inkscape.dev/inkscape/trunk

Revision history for this message

Alvin Penner (apenner) wrote on 2014-04-17:

circle007.svg Edit (2.3 KiB, image/svg+xml)

Revision history for this message

Alvin Penner (apenner) wrote on 2014-04-17:

re-posting a proposed solution from Bug 1244861, comment 7

This can be fixed in the file 2geom\ellipse.cpp, routine Ellipse::transformed, line 236.
replace the line:
if ( are_near(AM.det(), 0) )
with the line:
if ( are_near(std::sqrt(AM.det()), 0) )

This line is used to bypass the normal processing of a circle if the object is too small. The determinant is used to measure the size of the object. Unfortunately, the determinant is a quadratic function of the radius, when the size measurement should be a linear function of radius, so it approaches zero more rapidly than desired at small radius. Taking the square root avoids the problem.
Unfortunately, this is in 2geom, so I am reluctant to commit this change, thought I would ask for comment here, from anyone who is more familiar with 2geom.

Revision history for this message

su_v (suv-lp) wrote on 2014-04-17:

Reproduced with r13289 on OS X 10.7.5.

No meaningful backtrace beyond this:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00007fff5f3fff18
0x000000010063fff2 in geom_cubic_bbox_wind_distance (x000=1907.0000682160608, y000=-3113.4675617756534, x001=-nan(0x8000000000000), y001=inf, x011=-nan(0x8000000000000), y011=-nan(0x8000000000000), x111=-nan(0x8000000000000), y111=-nan(0x8000000000000), pt=@0x7fff5fbfe6a8, bbox=0x0, wind=0x7fff5fbfdff4, best=0x7fff5fbfdff8, tolerance=0.5) at geom.cpp:270
270 const Geom::Coord Px = pt[X];
(gdb) bt
#0 0x000000010063fff2 in geom_cubic_bbox_wind_distance (x000=1907.0000682160608, y000=-3113.4675617756534, x001=-nan(0x8000000000000), y001=inf, x011=-nan(0x8000000000000), y011=-nan(0x8000000000000), x111=-nan(0x8000000000000), y111=-nan(0x8000000000000), pt=@0x7fff5fbfe6a8, bbox=0x0, wind=0x7fff5fbfdff4, best=0x7fff5fbfdff8, tolerance=0.5) at geom.cpp:270
#1 0x0000000100640875 in geom_cubic_bbox_wind_distance (x000=1907.0000682160608, y000=-3113.4675617756534, x001=-nan(0x8000000000000), y001=inf, x011=-nan(0x8000000000000), y011=-nan(0x8000000000000), x111=-nan(0x8000000000000), y111=-nan(0x8000000000000), pt=@0x7fff5fbfe6a8, bbox=0x0, wind=0x7fff5fbfdff4, best=0x7fff5fbfdff8, tolerance=0.5) at geom.cpp:345
...