Hi Jake, It may be worth trying the latest 1.4.2 stable release if possible since a few leaks were plugged with that including:
commit 17f951b8f9f686042de2b414601fb9e3c3a6723a Author: Neil Roberts <[email protected]> Date: Wed Sep 29 15:40:22 2010 +0100 cogl-texture-2d-sliced: Don't create the slice textures twice Both of the cogl_texture_2d_sliced_new functions called the slices_create function which creates the underlying GL textures. However this was also called by init_base so the textures would end up being created twice. This would make it leak the GL textures and the arrays which point to them. if that doesn't help then it's likely to be a rogue reference to a CoglTexture that someone isn't freeing. There isn't really any recipe for debugging that kind of leak but in gdb you can try breaking on cogl_texture_new_from_file() to see where the texture is first created and then set a watchpoint on the ref_count of the texture and hopefully by seeing who takes references to the object you can figure out who forgets to free it after destroying your actor. If you get stuck it would be good if you could show a simple test case that reproduces the leak and attach it to a bug and then hopefully we can track it down. kind regards, - Robert Excerpts from Jake Knickerbocker's message of Thu Dec 02 06:19:34 +0000 2010: > I'm wondering if someone here can point me in the right direction. > Simple test app. (Attached) > CEX100 backend. > GLES. > Clutter compiled with --with-imagebackend=internal > > Basically textures are not being freed by clutter_actor_destroy and I > eventually > crash out with a: > > GLib-ERROR **: gmem.c:170 failed to allocate > > Where might this leak be? That's a little open ended isn't it? I > guess I'm just > wondering what the usualy suspects might be. > > Thanks, > Jake -- Robert Bragg, Intel Open Source Technology Center _______________________________________________ clutter-app-devel-list mailing list [email protected] http://lists.clutter-project.org/listinfo/clutter-app-devel-list
