Delivered-To: lablgtk at yquem.inria.fr Date: Wed, 09 Jan 2008 22:28:06 +0900 (JST) Message-Id: <20080109.222806.186490198.garrigue at math.nagoya-u.ac.jp> To: jon at ffconsultancy.com Subject: Re: [Lablgtk] Leaking pixmaps From: Jacques Garrigue In-Reply-To: <200801091254.46023.jon at ffconsultancy.com> References: <200801091053.51621.jon at ffconsultancy.com> <20080109.215209.2004159811.garrigue@math.nagoya-u.ac.jp> <200801091254.46023.jon@ffconsultancy.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: lablgtk at yquem.inria.fr Content-Type: Text/Plain; charset=us-ascii Content-Length: 1907 From: Jon Harrop > On Wednesday 09 January 2008 12:52:09 Jacques GARRIGUE wrote: > > From: Jon Harrop > > > > > Has anyone found a bug where using pixmaps causes a memory leak resulting > > > in X consuming all memory and dying? > > > > > > I just ditched pixmaps in favour of direct rendering which fixed the > > > problem and the symptom deterred me from investigating... > > > > This is not a bug, but the normal behaviour since pixmap are on the > > server side, and it would be complicated to manage them properly. > > This is the reason there is a Gdk.Pixmap.destroy function, so that you > > can destroy pixmaps early when you don't need them anymore. > > examples/timer.ml shows how to use it. > > When using OpenGL from OCaml, I wrapped handles to external resources like > display lists and textures in objects and finalized them so OCaml's GC > collected the external resource. That worked extremely well but partly > because OpenGL does not leak resources after application death as X seems to. > Perhaps a similar scheme could be useful here? Pixmaps are finalized, like all external resources in lablgtk. But pixmaps can be huge, and you may end up using lots of space before the GC collects them, so it is better to destroy them explicitly. > Also, I've managed to reproduce the problem without pixmaps. The > leak seems to be with colors now. Can I deallocate a color? That's rather strange. Colors are allocated on the caml heap (i.e. they are directly managed by the GC), and only take a few bytes. I ran your program, but wasn't able to reproduce the problem (everything works fine). It may be related to a specific color mode you are using. What is the output of xdpyinfo? Jacques _______________________________________________ Lablgtk mailing list Lablgtk@yquem.inria.fr http://yquem.inria.fr/cgi-bin/mailman/listinfo/lablgtk