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

[Martin J. <ja...@pi...>]

Benjamin Otte 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.

OK, makes sense.  Please disregard #108263, then.  I've marked it as 
RESOLVED/NOTABUG.


> And please go on digging through the code and file more bugs,
> mail to the list or drop on IRC and ask.

No problem.  For what it's worth, I just entered #109064, which is a 
minor cleanup for gstudpsrc.c, setting the address length before 
recvfrom(); and #109069, which fixes the initialization of the 
xvideosink.c plugin, removing a small X window leak.  Both have patches 
attached.  I'd appreciate it if someone would review, and apply as they 
see fit.


> 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.

No problem; it's a cool platform (even if it's not C++! :), with some 
very neat tools.


 > [re. gstqueue memory leaks]
> I just commited a patch to HEAD to fix these leaks, so it should be in
> 0.6.1, too.

Good stuff, thanks!  I've been chasing a memory leak, possibly 
queue-related, possibly not; so I'll see whether this helps.

Cheers...

-- 
Martin Janzen
ja...@pi...