This file causes a crash when semi circle is moved

Confirmed on Windows 7 x64. No usable backtrace as binary was not compiled with debugging symbols.

Reproduced on Crunchbang Waldorf, Inkscape trunk revision 13426.
Not reproduced with 0.48.3.1.

GDB trace attached.

I would not chalk this up to a 2geom issue but rather one with libvarot, the "library" that we use mainly for boolops and stroke outlines.

This patch stops the error:

=== modified file 'src/2geom/path.cpp'
--- src/2geom/path.cpp 2014-04-06 21:54:56 +0000
+++ src/2geom/path.cpp 2014-06-19 23:27:23 +0000
@@ -383,7 +383,7 @@
     final_->setPoint(1, c->initialPoint());
   } else {
     if (c->initialPoint() != finalPoint()) {
- THROW_CONTINUITYERROR();
+ return; //THROW_CONTINUITYERROR();
     }
   }
   get_curves().insert(get_curves().end()-1, boost::shared_ptr<Curve>(c));

Basically that throw isn't caught, death to inkscape. No ill effects are experienced with a simple return here. thoughts?

@Martin,

Please don't do that — catch the exception in livarot, but please, don't stop it from being thrown. This can make future bugs regarding this situation virtually undetectable since we don't know what causes it.

Consequence pre-understood. Will have to catch error in livarot, although understanding what is going on is also important. It looks like the order of the end point isn't decoded correctly. Something is wrong with the reading of the svg, so that should be fixed too IMO.

Have not looked at this *at all*, so could be useless but: these continuity exceptions can happen when a curve with a NaN point value is appended to the path. Upon adding, 2geom doesn't throw, but it throws upon applying a transform to a path with NaN points.

@~suv:

What revisions might have lead to trunk keeping the "A" in path data longer?

I am not entirely convinced that line 383 of path.cpp is the source of the problem

- on my machine, Windows XP, Inkscape rev 13470, I have not been able to produce a crash
- however there is something unusual about the svg. The first arc is given by
  M 108.4 12.2 A 4.801 4.801 0 0 1 108.4 12.2
  In svg this type of construction is illegal because the start point of the arc is the same as the endpoint. Hopefully, if all goes well, the parser will ignore this arc entirely. If it does not ignore it, then it will almost certainly lead to a crash, probably a divide by zero. However, the crash will be caused by the fact that two points are the same, not by the fact that they are unequal as tested in line 383.
- The remaining two arcs, after this, look normal: they both represent 90 degree arcs.

Fix committed in lp:inkscape, r13492.

@Alvin

Thanks for the help in resolving this issue.

- no problem, glad to see that it was related to that issue.
- the only thing is, I think this change will need to be applied directly to lib2geom, otherwise it will get overwritten next time a sync is done. perhaps an email to
<email address hidden>
would start the ball rolling

Important information here:
http://www.w3.org/TR/SVG/implnote.html#ArcImplementationNotes
"If the endpoints (x1, y1) and (x2, y2) are identical, then this is equivalent to omitting the elliptical arc segment entirely."

Committed to lp:lib2geom, r2245

Anytime we need to upstream: First check if the project is on launchpad or similar service that allows annonimous branches so we can give the upstream the patch directly in code. Second check for bug trackers (for instance libcroco -> Gnome bugzilla) where we can attach a bug patch. And then we can hit up email addresses