Hi,

I've spent a lot of time (on many occasions) trying to pinpoint the
source of a *huge* memory leak in libchamplain (both when using Clutter
0.8.8 or 0.9).

For all I can tell, the loaded images are leaked at a crazy rate.  But
the actual image data is never kept in memory elsewhere than in Clutter
(they are created using clutter_texture_new_from_file).  The actors
refcounting has been validated and they are eventually destroyed.

Tonight, I've used valgrind.  Here is the output:

==29638== 10,633,903 bytes in 570 blocks are still reachable in loss
record 266 of 266
==29638==    at 0x4C21540: memalign (vg_replace_malloc.c:460)
==29638==    by 0x4C215FA: posix_memalign (vg_replace_malloc.c:569)
==29638==    by 0x6C1A0A0: slab_allocator_alloc_chunk (gslice.c:1136)
==29638==    by 0x6C1B908: g_slice_alloc (gslice.c:661)
==29638==    by 0x6BD8CF1: g_array_sized_new (garray.c:86)
==29638==    by 0x6C26860: g_static_private_set (gthread.c:451)
==29638==    by 0x6BE6182: g_get_filename_charsets (gconvert.c:1185)
==29638==    by 0x6BE61ED: _g_convert_thread_init (gconvert.c:1290)
==29638==    by 0x6C26AE4: g_thread_init_glib (gthread.c:165)
==29638==    by 0x401827: main (launcher.c:93)

This points out to cogl.  It looks like it doesn't free the slices of
the texture it makes.  I tried giving COGL a look but couldn't find
anything myself.  Any body else has a clue?

Thanks,
Pierre-Luc

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to