GNOME Bugzilla – Bug 647756
[bin] Posting EOS message although not reached PLAYING yet
Last modified: 2012-08-14 08:04:46 UTC
With the encodebin unit test in -base an interesting race condition is exposed. The unit test sets the pipeline to PLAYING, waits for the EOS message, then releases the request pads and then sets the pipeline to NULL. The EOS message arrives before the complete pipeline has finished the state change to PLAYING (the sinks are PLAYING already) and then the pad releasing will set internal elements of encodebin to NULL and remove them from encodebin. Because an async state change is still happening these elements are set to PLAYING again afterwards (although they're not a child element of encodebin anymore) and during disposal GstElement complains that the state is not NULL. The assertion can be fixed by releasing the encodebin pads after setting the pipeline to NULL. It can also be fixed by checking in GstBin if an element is still the child of the bin before changing the state and by setting the state of the elements to NULL *after* removing them from the bin. I'll file a separate bug for the GstBin child element problem.
Bug #647760 and bug #647757 are related to this one and are the cause why the unit test actually results in the assertions. Nonetheless it's probably wrong to get EOS before the pipeline is in PLAYING.
Reproducing this requires reverting of the following commit and running test_encodebin_render_audio_dynamic with .forever for example commit 10e0b85a5695eda8e7d358d49e00966a09df0569 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Thu Apr 14 12:55:00 2011 +0200 encodebin: Release pads after setting the state to NULL in the unit test See bug #647756.
Just a random thought but maybe this is caused by making GstBus lockfree when posting messages. Maybe previously the async-done messages would be handled synchronously and the state change will be finished and only afterwards the EOS message can be handled. Now there's no locking anywhere and messages can be handled at the same time.
I'll check this tomorrow
As I said on IRC, I think this is counter-intuitive and think that the pipeline should delay posting the EOS message until it's reached PLAYING state.
Sure, that's one way to fix it but if my thought from comment #3 is correct this is not only affecting the EOS messages but all messages. Previously messages would be posted by the top-level bin in the order they were posted by the childs, now later messages can be posted first if threads change while the messages are forwarded to the higher-level bins (and especially if more than just forwarding is done, like with the async-done messages).
Nope, the mutex was only taken when adding messages to the queue so that can't be the reason why this happens. And it also happens with GstBus from last release. Can be easily shown by adding a g_assert (GST_STATE (pipeline) == GST_STATE_PLAYING) after the EOS message is received in the test.
Not marking as blocker, it's bad but definitely no regression :)
Created attachment 186196 [details] [review] bin: Only post EOS messages after reaching the PLAYING state Fixes bug #647756.
commit 7316a88387e3e5a36d792f4a6e95cbb9f05e9513 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Thu May 12 16:48:41 2011 +0200 bin: Don't interprete pipelines without sink elements as always being in EOS Some tests (e.g. elements/capsfilter) have pipelines with dangling sinkpads and without a sink element. These pipelines can never post an EOS message (because this is only valid by a sink) and as such should never get an EOS message posted by the bin. commit 4a836cae9fa9240d7ed3c6e5a9d7ea9afa484c0a Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Mon Apr 18 14:26:33 2011 +0200 bin: Only post EOS messages after reaching the PLAYING state Fixes bug #647756.
*** Bug 585268 has been marked as a duplicate of this bug. ***