[cairo] pixman crash from setting clip region on image surface(patch)

Maarten Breddels dmon at xs4all.nl
Sat May 8 08:14:42 PDT 2004


> -----Original Message-----
> From: cairo-bounces at cairographics.org 
> [mailto:cairo-bounces at cairographics.org] On Behalf Of 
> Vladimir Vukicevic
> Sent: zaterdag 8 mei 2004 10:59
> To: Carl Worth
> Cc: cairo at cairographics.org
> Subject: Re: [cairo] pixman crash from setting clip region on 
> image surface(patch)
> 
> 
> Hi Carl,
> 
> Carl Worth wrote:
> > On Wed, 05 May 2004 20:21:37 -0700, Vladimir Vukicevic wrote:
> > 
> >>The attached patch fixes this; just a patch to icimage.c to 
> check if the 
> >>region is not NULL before setting a new clipping region.
> > 
> > Thanks. This is committed.
> 
> More problems on this front, but I'm not sure what the fix is.  When 
> pixman gets a clip region set via 
> pixman_image_set_clip_region, it takes 
> ownership of this region and later destroys it in 
> pixman_image_destroyClip when the clip region is changed.
> 
> However, cairo also keeps track of the clip region in 
> gstate->clip.region, and calls pixman_region_destroy on it in 
> _cairo_gstate_fini, among others.  So, given that cairo 
> creates a region 
> in _cairo_gstate_clip, and then assigns it to gstate->clip.region and 
> calls _cairo_surface_set_clip_region() (which in turn calls 
> pixman_image_set_clip_region) using the same pointer, we end 
> up with a 
> double free in many places where pixman_region_destroy() is called in 
> cairo_gstate.c.
> 
> One solution is to always create a copy of the region before calling 
> _cairo_surface_set_clip_region (or that this function creates a copy 
> before calling the back end implementation); however, this would mean 
> that all the back ends would have to agree to clean up that region if 
> they don't use pixman_image_set_clip_region().
> 
> Any thoughts on how to fix this?
> 

Yes, I noticed some clipping bugs also, clipping under win32 is
unusable(unpredictable crashes), I guess the win32 api isn't as
forgiving as glibc. I thought it was (another) problem with cairo on
win32, glad someone found out there's a bug. 

-Maarten





More information about the cairo mailing list