After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 600269 - Gstreamer's Queue will leak Events in LEAK_DOWNSTREAM mode
Gstreamer's Queue will leak Events in LEAK_DOWNSTREAM mode
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.x
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-10-31 22:38 UTC by bens
Modified: 2009-11-03 16:56 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description bens 2009-10-31 22:38:35 UTC
While perusing the source code of Queue, I noticed that leak_downstream() appears to leak Buffers and Events:

http://cgit.freedesktop.org/gstreamer/gstreamer/tree/plugins/elements/gstqueue.c#n884

Notice that the value of is_buffer is never checked, so Events could easily be dequeued.  However, I have been told that even a leaking Queue should never lose an Event.

Either the code is incorrect, the documentation is misleading, or I am just not understanding the situation.
Comment 1 Wim Taymans 2009-11-02 09:51:37 UTC
It should not leak events
Comment 2 bens 2009-11-02 14:03:45 UTC
OK. Unfortunately, I'm not enough of a gstreamer expert to know how to test this, but I strongly suspect that events will be leaked in LEAK_DOWNSTREAM mode, if the element at the downstream end of the queue is running slower than real time, causing frequent queue leaking.
Comment 3 Wim Taymans 2009-11-02 16:51:38 UTC
Hard to fix, in some cases we do need to drop events as well (segment accumulation event), in other cases we shouldn't. I would suggest to not use the leaky options on queue as they are broken and not needed in a properly functioning pipeline.
Comment 4 bens 2009-11-02 21:06:44 UTC
Interesting.  I presume you mean that a properly functioning pipeline would use QoS messages to achieve the desired effect without leakiness?

For the record, I was reading the code while implementing leakiness in Cortado's jst Queue plugin [1].  I suppose QoS would be even better, but jst does not appear to have any support for QoS messages, so that seemed like a much larger project.

I suppose that makes this a CANTFIX.

[1] http://lists.xiph.org/pipermail/theora-dev/2009-October/004005.html
Comment 5 Stefan Sauer (gstreamer, gtkdoc dev) 2009-11-03 16:56:34 UTC
wtay, can't we check the type and iterate until we find a buffer (there is g_queue_pop_nth() ).