GNOME Bugzilla – Bug 705835
queue: Keeps sticky events around after pad deactivation
Last modified: 2013-08-19 14:39:40 UTC
Run the following test in a loop (in gdb): GST_START_TEST (b) { gboolean have_queue = TRUE; GstElement *pipeline, *src, *queue, *sink; pipeline = gst_pipeline_new ("pipeline"); src = gst_check_setup_element ("videotestsrc"); queue = gst_check_setup_element ("queue"); sink = gst_check_setup_element ("fakesink"); gst_bin_add_many (GST_BIN (pipeline), src, queue, sink, NULL); g_object_set (src, "num-buffers", 3, NULL); if (have_queue) { fail_unless (gst_element_link (src, queue)); fail_unless (gst_element_link (queue, sink)); } else fail_unless (gst_element_link (src, sink)); gst_element_set_state (pipeline, GST_STATE_PLAYING); sleep (0.1); gst_element_set_state (pipeline, GST_STATE_NULL); sleep (0.1); if (1) { gst_element_set_state (pipeline, GST_STATE_PLAYING); sleep (0.1); gst_element_set_state (pipeline, GST_STATE_NULL); } gst_object_unref (pipeline); } GST_END_TEST; After a couple of loops the the test results in the following error: GStreamer-WARNING **: gstpad.c:4506:store_sticky_event:<queue:src> Sticky event misordering, got 'caps' before 'stream-start' Debugging further, it seems that the queue is not empty when changing the state of the pipeline from READY to NULL. Flushing the queue in this state seems to solve the problem. Some observations: 1. the problem is not reproducible without the queue element 2. replacing the queue element with the queue2 does not result in sticky-event-problem
Our assumption is that the queue element fails to dequeue any internally enqueued serialized events (and buffers?) when it is going READY->NULL. The queue element source code does not implement any change-state function and so it seems to confirm the bug (unless there is trickery going on with the pad (de)activation function which seems to be able to dequeue events too, but it is unknown when the (de)activation function should be called and under what circumstances it does dequeuing). The queue element goes through these state changes: NULL1->READY1->PLAYING1->READY2->NULL2->READY3->PLAYING2->READY4->NULL3 The sticky events on the sinkpad and srcpad were printed after having reached NULL2 and NULL3 (after the two gst_element_set_state (pipeline, GST_STATE_NULL) above). No events were sticking to the pads. The queue's source code shows that any serialized events are enqueued in the internal queue. In the bug report above "Flushing the queue" refers to dequeuing the internally enqueued serialized events. We test-implemented a change-state function which dequeues the enqueued events when going READY->NULL and this makes it impossible for us to reproduce the warning. At the moment I am not convinced that dequeuing the elements in a change-state function is 100% due to being unfamiliar with the code. I haven't understood the activation function.
Pad activation/deactivation happens in READY<->PAUSED, so in theory that should already do everything correctly.
Can you reproduce this with git master? I can't, I've been running this test in a loop for a few minutes without ever getting any warnings.
Yes, I can. I run the test in gdb (tcase_add_loop_test (tc_chain, b, 0, 10000000)). I get the problem after a couple of seconds.
Ah, I didn't try it in gdb. Maybe that changes the timing in the right way to trigger this bug
Ok, can confirm it here
commit b40599f6db3ed12db57b7acfdaa23e2f5d7a629a Author: Sebastian Dröge <slomo@circular-chaos.org> Date: Mon Aug 19 16:38:50 2013 +0200 multiqueue: Clean up after the streaming thread has stopped https://bugzilla.gnome.org/show_bug.cgi?id=705835 commit d7c3be226cc808e049e3111ae32ff880b19bee00 Author: Sebastian Dröge <slomo@circular-chaos.org> Date: Mon Aug 19 16:38:40 2013 +0200 queue2: Clean up after the streaming thread has stopped https://bugzilla.gnome.org/show_bug.cgi?id=705835 commit ec1dd125c74f3b5d5b428a8fb74e08fb974e99c2 Author: Sebastian Dröge <slomo@circular-chaos.org> Date: Mon Aug 19 16:38:16 2013 +0200 queue: Clean up after the streaming thread has stopped https://bugzilla.gnome.org/show_bug.cgi?id=705835