Re: Memory leak with image surfaces
Chris Wilson <[email protected]>
| Newsgroups | gmane.comp.lib.cairo |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Jun 14, 2013 at 08:15:44PM +0200, Victor Goya wrote: > I ran into the same problem with larger PDF files, the decompressed > images are never freed. > > The issue seems to be related to the "COW snapshots" feature : > "_cairo_image_surface_snapshot" create a clone of the surface but set > the "owns_data" flag of both the surface and its clone to FALSE. This > can lead in a situation where neither the original surface nor its > clone own the data, this results in a memory leak because none of them > take the responsability to free it. > > My guess is that the clone should copy the "owns_data" flag of the > original surface before setting the "owns_data" flag of the original > surface to FALSE. This way the clone is responsible to free the data > only if the original surface owned it. I'm not quite sure about all > the implications of the attached patch, but it fixes the leak for my > use case. Your analysis is correct, and the fix is indeed that I should have marked the clone as owning the data along that fast path. Thanks! commit e079e4e2297810ceb10798cf310a7fafe39b18f0 Author: Chris Wilson <[email protected]> Date: Thu Jun 20 14:02:14 2013 +0100 image: Mark the data as owned after stealing the snapshot's image Victor Goya found that we ended up leaking memory after reading a PNG into an image surface and drawing that onto a PDF surface. In particular, he discovered that commit 0bfd2acd35547fc2bd0de99cc67d153f0170697d Author: Chris Wilson <[email protected]> Date: Mon Aug 13 01:34:12 2012 +0100 xlib: Implement SHM fallbacks and fast upload paths introduced a path to steal the image data for a snapshot (and thereby avoid a redundant copy), but that path then lead to the leak of the "owned" data. Reported-by: Victor Goya <[email protected]> Signed-off-by: Chris Wilson <[email protected]> -Chris -- Chris Wilson, Intel Open Source Technology Centre -- cairo mailing list [email protected] http://lists.cairographics.org/mailman/listinfo/cairo