[Bug 750397] CRITICAL: Race condition in GstBus
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Wed Oct 12 20:28:53 UTC 2016
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.
More information about the gstreamer-bugs
mailing list