GNOME Bugzilla – Bug 308619
id3demuxbin tries to free its ghost pad even if it was removed earlier
Last modified: 2005-07-02 13:19:54 UTC
id3demuxbin tries to free its ghost pad (id3->srcpad), for example when it gets from PAUSED to READY state, just by look at the internal variable, id3-srcpad. this is quite unfortunate, as if the pad was removed from the element by gst_element_remove_pad() from a user of the element, the internal srcpad pointer will point to an already freed pad, resulting sometimes to a segfault.
Created attachment 48142 [details] [review] patch that fixes the issue
The pad belongs to the element, I don't think anyone else is allowed to just remove it. Why would you want to do that anyway? Cheers -Tim
well, I can remove it with a totally valid, public API call: gst_element_remove_pad(). an element should not get into an incosistent state when a valid, public API call is executed on it. as for why I want to remove it: because I want to remove the typefind element from underneath id3demuxbin. it has the bad sideeffect that the typefinding is done again and again as the element is moved from PAUSED/PLAYING state to READY and the other way around. but as id3demuxbin:src is a ghostpad the typefind0:src inside it, I have to remove the ghost pad and create a new one that links to the element right of typefind0.
Then you shouldn't go to READY. If you really have issues with this, just copy it into your application. I doubt that this is something that we'd want to support. In this case, gst_element_remove_pad() should only be called by the element itself, not by the application.
well, it's not me show's taking it to ready. but if I remove an element from the pipeline, and put it into another one, gstreamer will for some reason take it through the READY state. and what do you mean by 'in this case'? like some API calls work only in Wednesdays, but not on Saturdays?
I think that if you want to remove the typefind, you should just do autoplugging internally in your app and prefer id3demux over id3demuxbin. As far as I'm concerned, the pad is owned by id3demuxbin and thus should not be free'ed. Adding this code would break other things, such as reuse of autopluggers... So sorry, but I won't accept this patch. Don't get me wrong, I see the issue that you're having and I acknowledge it. I just think that the weel-behaviour of other applications is more important than the small replugging performance increase that some applications would see...
well, I still don't aggree with your point. while the specific issue at hand is autoplugging, the real issue is actually that a totally legal, public API call can make this element incosistent. and I think this is very dangerous. as for your suggestion, for doing autoplugging 'internally' - you're actually suggesting to duplicate functionality here - that I should write another autoplugging framework. but why would I do that? I'd rather patch the typefind element then, to have a freeze option - so that it won't re-autoplug when going to READY and than back to PAUSED state...
FWIW, I've clarified the API docs for gst_element_remove_pad() a bit now. Cheers -Tim