GNOME Bugzilla – Bug 604091
tee: cleanup requestpads in dispose
Last modified: 2009-12-09 12:34:05 UTC
There is a race in gst_tee_buffer_alloc(), where you can dispose the tee, and the allocpad will no longer be valid. By making sure the tee's own release_pad () is called, this marinal window of error is closed :)
Created attachment 149351 [details] [review] patch
Hm, the releasing of pads should probably be done in READY->NULL already, not when disposing the object completely. Not sure... And then gst_tee_buffer_alloc() should call gst_pad_get_parent() instead of GST_PAD_PARENT() to make sure that it owns a reference to the parent.
I don't think releasing pads should be done in NULL, you are allowed to set your connected pipeline to NULL, and then bring it back to PLAYING and still have all connectivity intact, I think.
Yes, you're right... I guess the patch is good then but doesn't fix this problem in all cases. gst_tee_buffer_alloc() should be made threadsafe
I was wondering if we couldn't call the release_pad function from the element _dispose function. We could probably follow the oadtemplate and see if this was a request pad and then release it.
Releasing the pads in gstelement dispose does not work. Some elements (adder) have already executed their dispose method before chaining up and then the datastructures needed to execute the _release are not there anymore. It looks like we need to add a manual release in all elements. commit 494495eae6a7892397deace4557d668f742f5822 Author: Havard Graff <havard.graff@tandberg.com> Date: Tue Dec 8 17:21:47 2009 +0100 tee: release pads in dispose Make sure to release all request-pads in the dispose-method, in case of a shutdown-race, where a pad-alloc is about to happen. Fixes #604091