GNOME Bugzilla – Bug 691698
Memory corruption: gst_pad_get_pad_template_caps returns a reference on GST_CAPS_ANY
Last modified: 2013-01-29 11:45:53 UTC
Inside gst_pad_get_pad_template_caps function in gstpad.c, if the pad does not have a padtemplate it returns a reference on GST_CAPS_ANY that has been previously referenced with gst_caps_ref (). The problem with this is that there is no shared access protection with a mutex for instance. gst_pad_get_pad_template_caps () is called in gst_pad_proxy_query_caps () which can be called by several threads and this might lead to memory corruption. I think a new gstcaps of type ANY should be return using gst_caps_new_any (), see the patch in attachment.
Created attachment 233421 [details] [review] Patch
GST_CAPS_ANY is initialized during gst_init() and never freed (so there's always at least one reference). gst_caps_ref() is increasing the refcount of that atomically and returning the new reference. If you get any memory corruption, most likely some code is not handling refcounting on the caps correctly. Do you have a testcase to reproduce the memory corruption?
Thanks for your answer Sebastian. I agree with you but is there no risk to do like it's done right now because if several threads tried to ref or unref GST_CAPS_ANY that might lead to memory corruption. No? Actually, the issue was coming from my own local code where GST_CAPS_ANY was used without referencing it and later on unref... By the way, I would expect from elements to always have a padtemplate on their sink and src pads. In the description of input-selector there is a padtemplate for each sink and src pads but when asking for its src pad template caps with gst_pad_get_pad_template_caps () we can see there is no one and the function returns a new reference of GST_CAPS_ANY. I didn't check the code of input-selector but I'm wondering if it's normal. So this bug is not from GStreamer if there is no risk of memory corruption as discussed in the first part of this comment. I apologize for disturbing :)
(In reply to comment #3) > Thanks for your answer Sebastian. I agree with you but is there no risk to do > like it's done right now because if several threads tried to ref or unref > GST_CAPS_ANY that might lead to memory corruption. No? No, gst_caps_ref() and all the ref()/unref() functions are threadsafe > Actually, the issue was coming from my own local code where GST_CAPS_ANY was > used without referencing it and later on unref... GST_CAPS_ANY is unowned by the caller, you either have to call ref() on it or not call unref() on it later. You must call ref() on it if you intent to change it. > By the way, I would expect from elements to always have a padtemplate on their > sink and src pads. In the description of input-selector there is a padtemplate > for each sink and src pads but when asking for its src pad template caps with > gst_pad_get_pad_template_caps () we can see there is no one and the function > returns a new reference of GST_CAPS_ANY. I didn't check the code of > input-selector but I'm wondering if it's normal. Yes, input-selector accepts ANY caps.