[gst-devel] memory leaks

[in7y118 at public.uni-hamburg.de]

Quoting Andy Wingo <wingo at pobox.com>:

> I was running gstreamer through valgrind today. Valgrind is cool, yo!
> We're pretty good -- it doesn't catch any uninitialized value errors,
> which is nice. We did have some memory leaks, however, which I've fixed.
> The only interesting memleak was the fact that GST_DEBUG_FUNCPTR_NAME
> allocated memory. I fixed that by caching any generated function name in
> the hash table that was already there. That was a largish leak that grew
> over time, considering that gst_pad_push had a DEBUG statement in it
> that printed the function name.
> 
D'oh, I'm stupid. I should have thought about that when I thought about how to 
make GST_DEBUG_FUNCTPTR return const gchar*. Thanks for finding that simple way.

> Each iteration after that
> then causes about 3 kB to be allocated and freed, a number that I'd like
> to get to, well, zero -- realtime apps can't malloc or free in their
> processing loops. 
>
You did run with debugging disabled, right? GST_DEBUG_* uses g_strdup_printf.
If you haven't: --gst-disable-debug switches that off.

> That's the status, yo. Happy hacking.
> 
Running an mp3 decode through oprofile showed that we don't even spend much 
time in the core lib. Apart from debugging the most time was spend in 
gst_bin_iterate, which is a good sign. So we're good wrt memory and speed.

Benjamin