GNOME Bugzilla – Bug 761912
gstpad: Fix race between gst_element_remove_pad and state change
Last modified: 2016-03-29 07:33:55 UTC
Created attachment 320949 [details] [review] patch When going from READY to NULL all element pads are deactivated. If simultaneously the pad is being removed from the element with gst_element_remove_pad() and the pad is unparented, there is a race where the deactivation will assert (g_critical) if the parent is lost at the wrong time. The proposed fix will check parent only once and retain it to avoid the race. The patch does not have a separate test, as the existing funnel-stress test will provoke this eventually, specially if a sleep is added in the code before getting the parent. It is in other words a very rare unlikely race, but a real one nevertheless.
<hgr1> anyone feel like reviewing https://bugzilla.gnome.org/show_bug.cgi?id=761912 ? <slomo> hgr1: sounds similar to another bug thiagoss created some weeks ago <slomo> hgr1: but makes sense to me
commit 7dd76b626e0dacdba2844243944ec6c14ddf6932 Author: Stian Selnes <stian@pexip.com> Date: Wed Jan 27 11:46:06 2016 +0100 pad: Fix race between gst_element_remove_pad and state change When going from READY to NULL all element pads are deactivated. If simultaneously the pad is being removed from the element with gst_element_remove_pad() and the pad is unparented, there is a race where the deactivation will assert (g_critical) if the parent is lost at the wrong time. The proposed fix will check parent only once and retain it to avoid the race. https://bugzilla.gnome.org/show_bug.cgi?id=761912