GstBase/PushSrc GstBuffer ownership

[Samuel Hurst]

Hi Tim,

Thanks for the quick response!

On 26/03/2015 18:51, Tim Müller wrote:

> 
> What you do in your create function sounds right.
> 
> What happens is basically that you give ownership of that buffer ref to
> the base class (who will then either unref the buffer, or push it
> downstream with gst_pad_push(), which passes ownership to the next
> element).

That's what I thought was supposed to happen, but got confused when
valgrind found the leak inside my code.
> 
> What you're seeing here is mostly likely a downstream element not
> freeing a buffer it has received correctly. What's the full pipeline?

I'm running a DASH playback chain with my curlhttpsrc element with a
patched dashdemux as the downstream element. The patches were done to
fetch multiple DASH representations instead of just one per adaptation
set for our specific use case.

I'll take a look at all the downstream elements and see how they're
dealing with buffers, maybe some of the changes we've introduced have
caused this. I'm guessing I should be on the lookout for that
gst_buffer_unref() function in the downstream elements instead then? Or
is there some other function that does it?

> It's a bit curious that it says 'still reachable' and not 'definitely
> lost', so perhaps the buffers are held in a cache somewhere that's not
> cleaned up properly?
> 

Your guess is as good as mine on that one! I don't know if
GStreamer/GLib keeps some internal reference of buffers? That's the only
thing I can think of.

> (I guess they might still be cached by GLibs or libc's allocator, but
> make sure to run valgrind with G_SLICE=always-malloc valgrind ... if you
> aren't doing that yet.)

I am indeed!

Thanks,
Sam