GNOME Bugzilla – Bug 755342
element: state_change may fail because of release_request_pad (racy)
Last modified: 2015-09-24 10:15:20 UTC
gst_element_state_change() may unexpectedly fail if the element is releasing a request pad simultaneously. gst_element_state_change() will iterate over the pads and activate/deactivate. If the timing is unfortunate and the pad is deactivated and removed (from release_pad function) after the iterator is created and while activate_pads() is called, gst_pad_set_active() may be called from activate_pads() on a pad with no parent causing gst_element_state_change() to return GST_STATE_CHANGE_FAILURE. This may happen on both activation and deactivation from gst_element_state_change(). This behavior has changed since 0.10 since no parent was needed then.
I guess the solution would be to check afterwards if things fail if the pad is still a child of the element?
Created attachment 311752 [details] [review] element: Ignore activate result for removed pads on state change This fixes a race where gst_element_change_state() may return failure if it has request pads that are deactivated and removed (and thus have no parent) at the same time as the element changes state and (de)activates its pads.
Review of attachment 311752 [details] [review]: Looks good but ::: gst/gstelement.c @@ +2691,3 @@ + if (GST_PAD_PARENT (pad) != NULL) { + cont = FALSE; + g_value_set_boolean (ret, FALSE); Same change needed in gstbin.c (search for gst_pad_set_active())
Created attachment 311854 [details] [review] bin: element: Ignore activate result for removed pads on state change This fixes a race where a state change may return failure if it has request pads that are deactivated and removed (and thus have no parent) at the same time as the element changes state and (de)activates its pads.
commit 2c60b7eb1fc8851296e7bbb209663bb0c0e53f21 Author: Stian Selnes <stian@pexip.com> Date: Mon Sep 21 13:58:51 2015 +0200 funnel: Fix racy state change Iterator may need to be resynced, for instance if pads are released during state change. got_eos should be protected by the object lock of the element, not of the pad, as is the case throughout the rest of the funnel code. https://bugzilla.gnome.org/show_bug.cgi?id=755343