[gst-devel] memory leaks

[Andy Wingo]

So,

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.

But now, there's nothing that shows up in a simple fakesrc ! fakesink
pipeline, except for some GLib leaks. Yay! For the record, we end up
with about 680 kB of mallocated memory at the end. Just iterating the
pipeline one time made the program allocate and free about 9.5 MB, most
of which I expect is in the registry code. 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. GStreamer has a nice state-change system in place; the
only reason to malloc or free within the core during PLAYING is if the
pipeline topology changes, and perhaps it's not even necessary then if
we keep around GstMemChunks of the proper sizes...

That's the status, yo. Happy hacking.

wingo.