bin: Race condition between gst_bin_remove() and gst_bin_element_set_state() (and gst_element_set_locked_state())
We need to take the state lock here to ensure that we're not currently just before setting the state of this child element. Otherwise it can happen that we removed the element here and e.g. set it to NULL state, and shortly afterwards have another thread set it to a higher state again as part of a state change for the whole bin.
When adding an element to the bin this is not needed as we require callers to always ensure after adding to the bin that the new element is set to the correct state.
This is reliably reproducible in one application I have here after 14 to 20 hours.
!65 (merged) tried solving this but it causes regressions as we can't simply take the state lock from
gst_bin_remove(): it will then often be taken after the stream lock, but proper shutdown of elements requires the other way around so we get a deadlock due to locking order.
I believe this is unfixable in 1.0 and for 2.0 we should think about moving all the state handling into a dedicated thread and have it all controlled by the top-level pipeline.