And here is some analysis for the curious:
When rx or ry is very small, the coordinate arithmetic at the top of
rsvg-path.c function rsvg_path_arc leads to y1, y2 or x1, x2 being large
and actually equal (due to precision restrictions). This in turn has
distance d == 0 and then sfactor == infinity. sfactor get multiplied in
the calculation of xc and yc with x1-x0 or y1-y0, i.e. we compute
infinity*0. Thus xc or yc is nan (not a number), eventually making
th_arc also nan.
Now the twist: in the calculation of n_segs (number of segments in the
path), memory incrementally allocated for each in some dependent
function later, (int) nan is MIN_INT (i.e. <0) on some arches (including
amd64,...) or MAX_INT (i.e. very large) on others (those seeing
failures). The for loop happily executes until memory runs out the
latter, while on the former, it is never executed.
Kind regards
T.
Rerun of the patch:
--- librsvg-2.22.2.orig/rsvg-path.c
+++ librsvg-2.22.2/rsvg-path.c
@@ -114,8 +114,9 @@
cause divide by zero and subsequent NaNs. We should
really do some ranged check ie -0.001 < x < 000.1 rather
can just a straight check again zero.
+ And now we even do! http://bugs.debian.org/508443
*/
- if ((rx == 0.0) || (ry == 0.0))
+ if ((fabs(rx) < DBL_EPSILON) || (fabs(ry) < DBL_EPSILON))
return;
sin_th = sin (x_axis_rotation * (M_PI / 180.0));
--
Thomas Viehmann, http://thomas.viehmann.net/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
