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 352345 - Small race condition in the queue element
Small race condition in the queue element
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
Other Linux
: Normal normal
: 0.10.11
Assigned To: Wim Taymans
GStreamer Maintainers
Depends on:
Reported: 2006-08-22 07:53 UTC by Sjoerd Simons
Modified: 2006-10-11 10:12 UTC
See Also:
GNOME target: ---
GNOME version: ---

Proposed patch. Sorry for forgetting to attach it earlier (765 bytes, patch)
2006-10-05 09:53 UTC, Sjoerd Simons
committed Details | Review

Description Sjoerd Simons 2006-08-22 07:53:01 UTC

  I ran into a small race condition in the queue element today. I'm using a queue with just place for one buffer that's leaky downstream. Currently the queue does the following to detect/handle that it's full:

 while (gst_queue_is_filled (queue)) {
    g_signal_emit (G_OBJECT (queue), gst_queue_signals[SIGNAL_OVERRUN], 0);
    GST_QUEUE_MUTEX_LOCK_CHECK (queue, out_flushing);

While emitting the signal, the queue is not locked. So the loop task can take buffers from the queue. With a one place buffer this means that when the queue is locked again, which triggers an assertion in the downstream leak code.

I'll attach a patch that fixes this by rechecking if we have a full queue when the queue is locked again. Note that this slightly changes the semantics of the overrun signal in case of a leaky queue.. Currently it means that the queue was full and a buffer *is* dropped, with this patch it means that a buffer *might* be dropped

Probably a better fix would be to only signal overrun after dropping (or just before blocking), but that requires more changes then i had time for.

Comment 1 Tim-Philipp Müller 2006-10-05 09:46:36 UTC
You said you had a patch?
Comment 2 Sjoerd Simons 2006-10-05 09:53:54 UTC
Created attachment 74039 [details] [review]
Proposed patch. Sorry for forgetting to attach it earlier
Comment 3 Wim Taymans 2006-10-11 10:12:09 UTC
I moved the code in the leak_downstream case because we still want to emit the running signal in the normal non-leaky behaviour.

        Patch by: Sjoerd Simons <sjoerd at luon dot net>

        * plugins/elements/gstqueue.c: (gst_queue_chain):
        Recheck queue filledness after signalling the overrun when we're about
        to leak downstream because we released the lock when emitting the signal
        and the queue could be empty again. Fixes #352345.