[gstreamer-bugs] [Bug 123775] [api] setting state on element should force highest state change on parent

[bugzilla-daemon at bugzilla.gnome.org]

Please DO NOT reply to this by email. All additional comments should be made in
the comments box of this bug report.

 http://bugzilla.gnome.org/show_bug.cgi?id=123775
 GStreamer | gstreamer (core) | Ver: 0.8.0





------- Additional Comments From Ronald Bultje  2005-01-29 20:46 -------
Running only part 2 of the test shows that gst_thread_change_state() is never
called, and thus gst_thread_main_loop is never started, which causes the hang.
That's weird, because the child state change is being picked up:

DEBUG (0x9ee4848 - 307513:10:20.196742000)      GST_STATES(19266)
gstbin.c(714):gst_bin_child_state_change_func:<p> highest child state is READY,
changing bin state accordingly
LOG   (0x9ee4848 - 307513:10:20.196859000)      GST_STATES(19266)
gstbin.c(904):gst_bin_change_state_norecurse:<p> setting bin's own state

The reason appears to be that gst_bin_change_state_norecurse() calls
parent_class->change_state(bin) instead of GST_ELEMENT_GET_CLASS
(bin)->change_state (bin).

Changing that starts getting us into pitfalls, though, as setting fakesrc in a
thread to PLAYING locks up the application:

DEBUG (0x8f74848 - 307513:36:24.632583000)      GST_THREAD( 2648)
gstthread.c(428):gst_thread_change_state:<p> changing state from NULL to READY
LOG   (0x8f74848 - 307513:36:24.632676000)      GST_THREAD( 2648)
gstthread.c(436):gst_thread_change_state:<p> grabbing lock
DEBUG (0x8f74848 - 307513:36:24.632766000)      GST_THREAD( 2648)
gstthread.c(391):gst_thread_sync:<p> syncing thread, grabbing lock
LOG   (0x8f74848 - 307513:36:24.632855000)      GST_THREAD( 2648)
gstthread.c(409):gst_thread_sync:<p> caught thread

Which seems to indicate we're hanging in "g_mutex_lock (thread->iterate_lock);"
in gst_thread_change_state(), probably because of recursive state changes. The
logs indicate the same thing: setting src to READY makes the thread go to READY,
which des a recursive (!) state-cgange on the bin, which sets all kids to READY,
which sets the sink to READY, which sets the parent to READY because that didn't
complete yet (still same context!), which re-locks the mutex, hang. We need a
separate function or better code for non-recursive state changes on bins to fix
this.

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