[Bug 750397] CRITICAL: Race condition in GstBus

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=750397

Jonathan Matthew <notverysmart at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |notverysmart at gmail.com

--- Comment #6 from Jonathan Matthew <notverysmart at gmail.com> ---
I hit this pretty regularly in rhythmbox, where the crossfading player backend
uses gst_bus_timed_pop during preroll, and it messes up the glib mainloop
source (used during normal operation) which causes the whole UI to freeze.

Would retrying the read until successful be acceptable? At that point we know
that either there is a byte to read already, or we're racing another thread
that will write it soon. Unfortunately, I don't think this would work for the
win32 implementation - it looks like ResetEvent will succeed whether the event
is signaled or not.

I've tried 'while (RELEASE_EVENT (set) == 0) {}' out a bit on linux and it does
appear to fix the problem for me.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.