GNOME Bugzilla – Bug 683794
tests: decodebin test_reuse_without_decoders sometimes fails with not-negotiated error on bus
Last modified: 2015-02-16 18:22:33 UTC
-base/tests/check $ GST_CHECKS=test_reuse_without_decoders make elements/decodebin.forever .... Running suite(s): decodebin 0%: Checks: 1, Failures: 1, Errors: 0 elements/decodebin.c:195:F:general:test_reuse_without_decoders:0: Failure 'gst_bus_poll (GST_ELEMENT_BUS (pipe), GST_MESSAGE_ERROR, 0) != NULL' occured Not sure what the deal with this is. At first I thought it was a race with the async-done being posted and the main thread shutting down the pipeline, but that shouldn't really be the case, because the fakesink is plugged into the pipeline and posts an async-start before decodebin sends its own async-done, so the pipeline-global async-done is ok as far as I can tell, also according to the logs. Possibly something doesn't get cleaned up or reset properly somewhere, since this change: tpm@zingle:~/gst/0.11/gst-plugins-base/tests/check$ git diff elements/decodebin.c diff --git a/tests/check/elements/decodebin.c b/tests/check/elements/decodebin.c index 26b14bd..ce59f25 100644 --- a/tests/check/elements/decodebin.c +++ b/tests/check/elements/decodebin.c @@ -172,7 +172,7 @@ GST_START_TEST (test_reuse_without_decoders) GST_DEBUG ("Resetting pipeline"); /* reset */ - gst_element_set_state (pipe, GST_STATE_READY); + gst_element_set_state (pipe, GST_STATE_NULL); sink = gst_bin_get_by_name (GST_BIN (pipe), "sink"); gst_bin_remove (GST_BIN (pipe), sink); makes it always work fine for me.
*** Bug 696388 has been marked as a duplicate of this bug. ***
After ~30min running: 0%: Checks: 1, Failures: 1, Errors: 0 elements/decodebin.c:147:F:general:test_reuse_without_decoders:0: Failed to create audiotestsrc element
For the record I just reproduced the original issue: Running suite(s): decodebin 0:00:00.030927846 20890 0x1b5c940 WARN GST_PADS gstpad.c:3742:gst_pad_peer_query:<typefind:src> could not send sticky events 0:00:00.031200686 20890 0x1b5c940 WARN basesrc gstbasesrc.c:2933:gst_base_src_loop:<src> error: Internal data flow error. 0:00:00.031235818 20890 0x1b5c940 WARN basesrc gstbasesrc.c:2933:gst_base_src_loop:<src> error: streaming task paused, reason not-negotiated (-4) 0%: Checks: 1, Failures: 1, Errors: 0 elements/decodebin.c:195:F:general:test_reuse_without_decoders:0: Failure 'gst_bus_poll (GST_ELEMENT_BUS (pipe), GST_MESSAGE_ERROR, 0) != NULL' occured
Found one issue: gst_decode_chain_free is called on paused -> ready and it will free the chains, but the decoded pad has a query handler that is blocked in the chain mutex waiting for the chain_free to end, but it will have freed the chain (and the mutex).
Created attachment 281646 [details] log for chain_free and query handling issue log of the above mentioned issue
I had the impression that state changes in bins were issued upstream->downstream or downstream->upstream depending if the state change was downwards or upwards, respectively. It seems I am wrong and it always goes from sinks to sources. Isn't this going to cause issues like the above if you interrupt a downstream element while upstream is still running? Don't we require applications to properly block pads when they need to do so? Shouldn't we handle this in core as well?
I can't reproduce this any more, let's close it. Lots of changes to that code since then.