[cairo] Clipping bogosity

Chris Wilson chris at chris-wilson.co.uk
Wed Apr 16 07:30:37 PDT 2008

Adrian Johnson was trying to understand an apparent bug in

Which appears quite bizarre, but it looks like it's just a bogus stack
trace. Performing the same steps under valgrind offers a clue:
==28204== Conditional jump or move depends on uninitialised value(s)
==28204==    at 0x560587E: _cairo_surface_set_clip
==28204==    by 0x561E489: _cairo_pdf_surface_emit_pattern
==28204==    by 0x561FCEE: _cairo_pdf_surface_show_page
==28204==    by 0x5605AAF: cairo_surface_show_page
==28204==    by 0x5612442: _cairo_paginated_surface_show_page
==28204==    by 0x5605AAF: cairo_surface_show_page
==28204==    by 0x51A78BC: gfxPDFSurface::EndPage()

This appears to be due to the use of _cairo_surface_(get|set)_clip() to
preserve the old clip around the replay of a meta-surface. As far as I
can see, the current surface clip is modified in-place and always points
at the clip embedded in the gstate. As such the attempt to save the clip
around the call to replay the surface is futile. I've attached a patch
to workaround the issue by perfoming a deep-copy of the clip onto the
stack - but I think _cairo_surface_get_clip() is itself fundamentally
flawed and a better API is required for preserving clips.

Chris Wilson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ps-pdf-Copy-the-old-clip-before-emitting-the-meta.patch
Type: application/mbox
Size: 0 bytes
Desc: not available
Url : http://lists.cairographics.org/archives/cairo/attachments/20080416/2142ddb3/attachment.bin 

More information about the cairo mailing list