[Gstreamer-bugs] Re: [Bug 108263] Changed - Possible race condition in gstqueue.c

[Benjamin Otte]

On Wed, 19 Mar 2003, Martin Janzen wrote:

> You're saying that if the queue->interrupt flag is set, the mutex
> unlocked, and gst_scheduler_interrupt() returns FALSE, then at some
> point between the unlock in 393 and the test in 398 the queue could
> have been flushed; in which case we want to return immediately based
> on the new state of queue->flush, not on its state before the unlock.
>
Right.
gst_scheduler_interrupt instructs the scheduler to finish the current
iteration. So, after a call to this function gst_bin_iterate returns. So a
lot can happen while that function is executed. (one example is explained
in the bug.
The return value of gst_scheduler_interrupt only indicates that the
current function should return asap. In the case of "FALSE", the function
may go on, which it does.

> If that's the case, then fair enough; my patch should not be applied,
> and #108263 changed to RESOLVED/NOTABUG.  (Also, it means I'll have to
> remove it from the enhancement I posted as #108268.  Moral of the
> story: Keep these separate!!)  Sorry for the false alarm.
>
I'll ask someone to review the bug once more and then close it (if I'm
right :). And please go on digging through the code and file more bugs,
mail to the list or drop on IRC and ask.
I don't care if you only post false alarms as long as you review the code.
Many thanks for liking GStreamer and reviewing us btw.

> Yes, and line 400 looks like one instance of this.  But maybe I'll
> let someone more familiar with schedulers, interrupts, etc. propose
> that patch! :)
>
I just commited a patch to HEAD to fix these leaks, so it should be in
0.6.1, too.

Benjamin