GNOME Bugzilla – Bug 647759
[bin] Element could be removed from the bin but still claim that the bin is the parent
Last modified: 2012-06-11 13:52:38 UTC
There's a race in gst_bin_remove_func(), first the element is removed from the bin with the bin/element object locks, both are released. Then the element is unparented. During this short period of time the element still claims that the bin is the parent. To prevent race conditions in code that checks if the child is really a child of the bin it is necessary to take both locks and additionally check the UNPARENT flag of the child. This should be documented.
Maybe that code should do like the add_func, take the bin lock, unparent and then update the bin state. This would also remove the need for the unparenting flag I think.
commit 26682f7c7aceb10782c3d8d9020ccc1e5dd3cb51 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Mon Jun 11 15:49:10 2012 +0200 element: remove unused UNPARENTING flag commit 85d5a29b400adc7047d9d14edcae4e17a0bb6136 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Mon Jun 11 15:41:58 2012 +0200 bin: reorganize _remove_func to avoid races Make the gst_bin_remove_func more like the add_func. Check if the element we try to remove from the bin has the bin as the parent and set the parent flag to NULL immediately, this allows us to avoid concurrent remove operations without using the UNPARENTING element flag. After we unparented the element from the bin, we update the bin state and remove the element from the list. Finally we unlink all the pads. This avoids a race condition where the element could still claim to have the bin as the parent while the bin didn't have a pointer to the element anymore. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=647759