[gst-devel] memory leaks

in7y118 at public.uni-hamburg.de in7y118 at public.uni-hamburg.de
Fri Aug 8 06:51:07 CEST 2003

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.


More information about the gstreamer-devel mailing list