GNOME Bugzilla – Bug 678017
gstfunnel: access of freed pad object
Last modified: 2012-06-14 13:13:09 UTC
Created attachment 216277 [details] [review] gstfunnel: avoid access of freed pad When running gst-rtsp-server in valgrind, I've found an issue in gstfunnel.c. In gst_funnel_release_pad, a pad object is accessed after a call to gst_element_remove_pad. This can be problematic, because gst_element_remove_pad may free the pad. The attached suggested patch avoids this problem.
While this seems right at first glance, I saw while looking further that gst_element_remove_pad is marked with "@pad: (transfer none):", which seems to conflict with the idea that the pad may be unreffed/destroyed. That annotation may be wrong, or I'm mistaken on the exact semantics of it.
The transfer none just means that if the caller owned a ref to the pad before calling _remove_pad(), it will still own that ref afterwards. It doesn't have anything to do with whether the pad may be unreffed by some other piece of code that previously held a ref (such as the element). It can't be destroyed though, because the caller needs to hold a valid ref while calling _remove_pad(). I *think* the element implementation of request_new_pad is wrong here, I think it should return a ref, but element_add_pad() took ownership of the pad after creating it. Perhaps compare with other elements such as tee.
After IRC discussion, I've changed the annotation to full, then pushed the original patch (0.10 and master): commit 066b515985897495cae32fca5b7eeeec260c40c9 Author: David Svensson Fors <davidsf@axis.com> Date: Tue Jun 12 13:26:35 2012 +0200 gstfunnel: avoid access of freed pad Save the value of the pad's got_eos in gst_funnel_release_pad, before calling gst_element_remove_pad. This is because gst_element_remove_pad may free the pad. https://bugzilla.gnome.org/show_bug.cgi?id=678017 Thanks