[Bug 750397] CRITICAL: Race condition in GstBus

[GStreamer (GNOME Bugzilla)]

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

Xavier Claessens <xclaesse at gmail.com> changed:

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

--- Comment #78 from Xavier Claessens <xclaesse at gmail.com> ---
Are those patches backported to 1.8? I think I'm hitting this bug as well.

My app runs on Windows7, it creates a thread with a GMainContext and attach
gst_bus_create_watch()'s source on it, with gst_bus_async_signal_func as
callback. Then I connect "message::state-changed" signal.

When doing a serie of "play->pause->seek->play" in loop, I always end up in a
state where I don't receive the "state-changed" PAUSED->PLAYING signal. This
leaves my app stuck in an inconsistent state where it thinks the seek never
finish (That code is similar to GstPlayer).

To be sure it's not a problem in my side, I even added a 1s timeout source on
the context to verify the thread polling the bus message queue is not stuck.
That source always continues working.

Using gst_bus_set_sync_handler() I do see the PAUSED->PLAYING "state-changed"
message, so I guess I'm hitting the race described here. Is that possible?

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