EVALUATION
Application creates a CubicCurve with NaNs as control points:
s1 = new CubicCurve2D.Double();
s1.setCurve(1.0, 1.0,
Double.NaN, Double.NaN,
Double.NaN, Double.NaN,
0.0, 0.0);
So we're crashing in ductus renderer running out of stack:
t@17 (l@18) signal SEGV (access to address exceeded protections) in processToRunsArc3 at line 729 in file "dcPathFiller.c"
729 if (x0 < x1) { arclox = x0; archix = x1; }
dbx: read of 32 bytes at address f1d07f78 failed -- Error 0
(dbx 5) w
current thread: t@17
=>[1] processToRunsArc3(env = (nil), p = (nil), x0 = 0.01564897, y0 = 0.03124998, x1 = NaN, y1 = NaN, x2 = NaN, y2 = NaN, x3 = NaN, y3 = NaN), line 729 in "dcPathFiller.c"
[2] processToRunsArc3(env = 0x87638, p = 0x16261c, x0 = 0.01564897, y0 = 0.03124998, x1 = NaN, y1 = NaN, x2 = NaN, y2 = NaN, x3 = NaN, y3 = NaN), line 814 in "dcPathFiller.c"
[3] processToRunsArc3(env = 0x87638, p = 0x16261c, x0 = 0.01564897, y0 = 0.03124998, x1 = NaN, y1 = NaN, x2 = NaN, y2 = NaN, x3 = NaN, y3 = NaN), line 814 in "dcPathFiller.c"
Note that we do not crash on windows because for some reason instead
of RunsBuilder_appendCubic (dcPathFiller) on solaris, which calls
processToRunsArc3, we call RunsBuilder_appendLine.
I'm reassigning the bug to the engineer working on boundary conditions
in Ductus renderer.
I don't believe this is a high priority bug: the app supplies unreasonable
input. While we definitely shouldn't crash, the workaround for the customer
is simple: chose some reasonable default values instead of NaNs.
###@###.### 2003-08-21
Fixed at java level by validating path segments and skiping ones with invalid
control points
###@###.### 2005-04-27 17:29:15 GMT
|