[Gstreamer-bugs] [Bug 108263] New - Possible race condition in gstqueue.c

[bugzilla-daemon at widget.gnome.org]

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.