[Gstreamer-bugs] [Bug 108263] New - Possible race condition in gstqueue.c
bugzilla-daemon at widget.gnome.org
bugzilla-daemon at widget.gnome.org
Wed Mar 12 20:20:39 PST 2003
Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.
http://bugzilla.gnome.org/show_bug.cgi?id=108263
Changed by janzen at pixelmetrix.com.
--- shadow/108263 Wed Mar 12 23:20:39 2003
+++ shadow/108263.tmp.8222 Wed Mar 12 23:20:39 2003
@@ -0,0 +1,38 @@
+Bug#: 108263
+Product: GStreamer
+Version: 0.6.0
+OS: All
+OS Details:
+Status: NEW
+Resolution:
+Severity: minor
+Priority: Normal
+Component: gstreamer (core)
+AssignedTo: gstreamer-maint at bugzilla.gnome.org
+ReportedBy: janzen at pixelmetrix.com
+QAContact: gstreamer-maint at bugzilla.gnome.org
+TargetMilestone: 0.6.x
+URL:
+Summary: Possible race condition in gstqueue.c
+
+In gstqueue.c, there appears to be the potential for a (highly unlikely,
+but not impossible) race condition in the gst_queue_chain() method when
+checking the 'flush' variable on a full queue:
+
+ if (queue->interrupt) {
+ GST_DEBUG_ELEMENT (GST_CAT_DATAFLOW, queue, "interrupted!!");
+ g_mutex_unlock (queue->qlock);
+ if (gst_scheduler_interrupt (gst_pad_get_scheduler (queue->sinkpad),
+GST_ELEMENT (queue)))
+ return;
+ /* if we got here bacause we were unlocked after a flush, we don't need
+ * to add the buffer to the queue again */
+ if (queue->flush) {
+ GST_DEBUG_ELEMENT (GST_CAT_DATAFLOW, queue, "not adding pending
+buffer after flush");
+ return;
+ }
+
+Note that the 'queue->flush' data member is tested after the mutex is
+unlocked. This should probably be copied to an automatic variable before
+the call to g_mutex_unlock(); see the attached patch.
More information about the Gstreamer-bugs
mailing list