<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Image compositor can pass invalid coordinates to pixman_fill()"
href="https://bugs.freedesktop.org/show_bug.cgi?id=90120#c8">Comment # 8</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Image compositor can pass invalid coordinates to pixman_fill()"
href="https://bugs.freedesktop.org/show_bug.cgi?id=90120">bug 90120</a>
from <span class="vcard"><a class="email" href="mailto:federico@gnome.org" title="Federico Mena-Quintero <federico@gnome.org>"> <span class="fn">Federico Mena-Quintero</span></a>
</span></b>
<pre>(In reply to Chris Wilson from <a href="show_bug.cgi?id=90120#c7">comment #7</a>)
<span class="quote">> Created <span class=""><a href="attachment.cgi?id=115240" name="attach_115240" title="Preliminary stroke validation">attachment 115240</a> <a href="attachment.cgi?id=115240&action=edit" title="Preliminary stroke validation">[details]</a></span> <a href='page.cgi?id=splinter.html&bug=90120&attachment=115240'>[review]</a> [review]
> Preliminary stroke validation</span >
This is really nice! It fixes the problem very cleanly - valgrind shows no
problems with the fuzzed file.
(And thanks for making me aware of CAIRO_STATUS_INVALID_SIZE; hopefully we'll
have a lot more of it in the future :)
<span class="quote">> Imo, the important thing here, if we take the input validation path, is to
> only apply it at the boundary of the fixed point representation i.e. so that
> we only reject extreme values when rastering, but pass through to vector
> backends (or apply their own range checking).</span >
Agreed.
<span class="quote">> However, extreme line_width has a very simple interpretation and I think it
> would be better for cairo to have a slow-but-safe rasteriser. Detecting when
> the input path and style will produce illegal fixed point values and
> switching to a double representation will allow us to generate output
> without crashing with a slight loss of precision.</span >
This would be nice in the get-everything-absolutely-correct sense of things,
but I'm not very concerned about it. If the caller gets a meaningful error
like CAIRO_STATUS_INVALID_SIZE, then it will know that something is amiss.
Chris, since you just put your foot into the rabbit hole :) May I interest you
in another fixed-point overflow thing? This goes back to the old bugs #20091
and #39096. Using this fuzzed svg
<svg>
<defs>
<clipPath id="clipper">
<rect y="19" width="2" height="2" />
<rect width="18446744073709551616" height="29" />
</clipPath>
</defs>
<g clip-path="url(#clipper)">
<g clip-path="url(#clipper)">
</g>
</g>
</svg>
with rsvg-view-3 and valigrind produces
==23663== Use of uninitialised value of size 8
==23663== at 0x6C1FFA1: insert_edge (cairo-boxes-intersect.c:458)
==23663== by 0x6C20063: sweep_line_insert (cairo-boxes-intersect.c:478)
==23663== by 0x6C201E1: intersect (cairo-boxes-intersect.c:516)
==23663== by 0x6C20DE4: _cairo_boxes_intersect (cairo-boxes-intersect.c:685)
==23663== by 0x6C270BB: _cairo_clip_intersect_boxes (cairo-clip-boxes.c:290)
==23663== by 0x6C26AAD: _cairo_clip_intersect_rectilinear_path
(cairo-clip-boxes.c:145)
==23663== by 0x6C2500D: _cairo_clip_intersect_path (cairo-clip.c:261)
==23663== by 0x6C34DE7: _cairo_gstate_clip (cairo-gstate.c:1559)
==23663== by 0x6C2DE30: _cairo_default_context_clip
(cairo-default-context.c:1103)
==23663== by 0x6C22A38: cairo_clip (cairo.c:2492)
==23663== by 0x4E5BD6C: rsvg_cairo_clip (rsvg-cairo-clip.c:170)
==23663== by 0x4E5A348: rsvg_cairo_push_discrete_layer
(rsvg-cairo-draw.c:777)
(gdb) where
#0 0x0000000006c1ffa1 in insert_edge (edge=0x7feffe640, pos=0x7feffe3e8) at
cairo-boxes-intersect.c:458
#1 0x0000000006c20064 in sweep_line_insert (sweep=0x7feffc3d0,
rectangle=0x7feffe640) at cairo-boxes-intersect.c:478
#2 0x0000000006c201e2 in intersect (rectangles=0x7feffe580, num_rectangles=4,
out=0x7feffeeb0) at cairo-boxes-intersect.c:516
#3 0x0000000006c20de5 in _cairo_boxes_intersect (a=0x7feffeeb0, b=0x7fefff130,
out=0x7feffeeb0) at cairo-boxes-intersect.c:685
#4 0x0000000006c270bc in _cairo_clip_intersect_boxes (clip=0x1246be00,
boxes=0x7fefff130) at cairo-clip-boxes.c:290
#5 0x0000000006c26aae in _cairo_clip_intersect_rectilinear_path
(clip=0x1246be00, path=0x12465a48, fill_rule=CAIRO_FILL_RULE_WINDING,
antialias=CAIRO_ANTIALIAS_DEFAULT) at cairo-clip-boxes.c:145
#6 0x0000000006c2500e in _cairo_clip_intersect_path (clip=0x1246be00,
path=0x12465a48, fill_rule=CAIRO_FILL_RULE_WINDING,
tolerance=0.10000000000000001, antialias=CAIRO_ANTIALIAS_DEFAULT) at
cairo-clip.c:261
#7 0x0000000006c34de8 in _cairo_gstate_clip (gstate=0x1246bc20,
path=0x12465a48) at cairo-gstate.c:1559
#8 0x0000000006c2de31 in _cairo_default_context_clip (abstract_cr=0x124656e0)
at cairo-default-context.c:1103
#9 0x0000000006c22a39 in cairo_clip (cr=0x124656e0) at cairo.c:2492
#10 0x0000000004e5bd6d in rsvg_cairo_clip (ctx=ctx@entry=0x12465cb0,
clip=0x1245e560, bbox=bbox@entry=0x0) at rsvg-cairo-clip.c:170
#11 0x0000000004e59077 in rsvg_cairo_push_early_clips
(ctx=ctx@entry=0x12465cb0) at rsvg-cairo-draw.c:718
#12 0x0000000004e5a349 in rsvg_cairo_push_discrete_layer (ctx=0x12465cb0) at
rsvg-cairo-draw.c:777
#13 0x0000000004e4ef8b in _rsvg_node_draw_children (self=0x12463600,
ctx=0x12465cb0, dominate=0) at rsvg-structure.c:83
#14 0x0000000004e4ef43 in rsvg_node_draw (self=0x12463600, ctx=0x12465cb0,
dominate=<optimized out>) at rsvg-structure.c:69
#15 0x0000000004e4efc3 in _rsvg_node_draw_children (self=0x124624a0,
ctx=0x12465cb0, dominate=0) at rsvg-structure.c:87
#16 0x0000000004e4ef43 in rsvg_node_draw (self=0x124624a0, ctx=0x12465cb0,
dominate=<optimized out>) at rsvg-structure.c:69
#17 0x0000000004e4f343 in rsvg_node_svg_draw (self=0x1245c4d0, ctx=0x12465cb0,
dominate=<optimized out>) at rsvg-structure.c:323
#18 0x0000000004e4ef43 in rsvg_node_draw (self=0x1245c4d0, ctx=0x12465cb0,
dominate=<optimized out>) at rsvg-structure.c:69
#19 0x0000000004e574e3 in rsvg_handle_get_dimensions_sub (handle=0x12455230,
dimension_data=0x7fefff838, id=<optimized out>, id@entry=0x0) at
rsvg-base.c:1424
#20 0x0000000004e57779 in rsvg_handle_get_dimensions (handle=0x12455230,
dimension_data=dimension_data@entry=0x7fefff838) at rsvg-base.c:1337
#21 0x0000000000403cc7 in main (argc=1, argv=0x7fefffc48) at test-display.c:773
(gdb) l
453 })
454 } while (TRUE);
455 }
456 }
457
458 pos->prev->next = edge;
459 edge->prev = pos->prev;
460 edge->next = pos;
461 pos->prev = edge;
462 }
(gdb) p pos->prev
$1 = (edge_t *) 0xe
(gdb) p *pos
$2 = {next = 0x7feffe668, prev = 0xe, right = 0x0, x = -2147483648, top = 0,
a_or_b = 306519600, dir = 0}
Please tell me if I should file this in a new bug, or in one of the old ones.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>