[gstreamer-bugs] [Bug 432755] [videorate] leaks buffer if flow != OK

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=432755

  GStreamer | gst-plugins-base | Ver: 0.10.x

Mark Nauwelaerts changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manauw at skynet.be
             Status|REOPENED                    |NEEDINFO




------- Comment #4 from Mark Nauwelaerts  2008-07-12 20:32 UTC -------
I have had a look at videorate and I can not find a leak (nor do the tests at
the moment).  Specifically, gst_video_rate_flush_prev cannot create a leak, as
it only adds 1 ref to a cached buffer and then gives away this ref to a
_pad_push (whatever that one's outcome may be).  It is indeed called in a few
places without checking the return value, as it would have little value in
those other cases (event handling), nor is there anything being leaked by not
checking the return value in those event cases.  _flush_prev need not take
ownership (of the cached buffer), since it is always replaced using _swap_prev,
which does not leak the previous one (and the state_change in any case cleans
the cache).

Regarding the IRC fragment:
* a pad_push always takes ownership (regardless of outcome), but note that it
is not the _chain's buffer (as an input parameter) that has been pushed, but a
previously cached buffer (or rather, an extra created ref to that cached
buffer), as all done in _flush_prev (the extra ref it creates is taken over by
the peer as a result of the _pad_push it performs, regardless of that result)
* similarly, _videorate_chain must take ownership of its input buffer, whether
it succeeds or fails.  Roughly, if it succeeds, the incoming buffer's ref is
retained as the buffer is put into the cache (by using _swap_prev), or the
incoming buffer is simply dropped (gst_buffer_unref) in case of some failure.
As far as I can tell, all _chain's code paths do either one of these, so the
input buffer can then not be leaked.
(and the original fix added a missing _unref to one of the failure paths)

Please indicate the suspected leak in more detail (or re-close this bug).


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=432755.