GNOME Bugzilla – Bug 762086
pad: Race between push and (de)activate leads to data flow before events
Last modified: 2018-11-03 12:33:05 UTC
Created attachment 321263 [details] [review] Test There is a race where data can be pushed without forwarding the sticky events. This test will trigger a g_warning about data flow before events. There's likely more than one race here, probably both for buffers and events. What can happen when trying to push a buffer while changing element state and thus (de)activating the pads is: 1. Pads are active and buffers are flowing as normal. 2. Element changes state and its pads are deactivated, during which the stored sticky events are removed. 3. A new buffer is pushed from a srcpad in the direction of the element's deactive sinkpad. 4. check_sticky() in gst_pad_push_data() will not send events since the flag PENDING_EVENTS on this srcpad is not set. 5. Before calling gst_pad_chain_data_unchecked() on the sinkpad, the pad will be activated (because of an element state change). The flag PENDING_EVENTS will be set, but it's too late for the srcpad to send the sticky events. 6. The event check in gst_pad_chain_data_unchecked() will fail and give g_warning. Any thoughts on how this should be resolved?
Some time ago we discussed this on IRC and the conclusion is that this doesn't represent a valid scenario. If the application is changing the state of an element while upstream threads are running freely it will cause unexpected side effects. The correct way to do this is using pad probes and then change the state of the downstream elements for whatever reason. Anyway let's see if someone else has a different opinion on it.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/157.