[gst-devel] GObjectClass.dispose() and GstElement

Gruenke, Matt mgruenke at Tycoint.com
Mon Jan 3 23:57:01 CET 2011


Based on my reading of the Plugin Writer's Guide & the GstElement
reference docs, elements are supposed to complete all of their
deallocation on the READY -> NULL transition.  However, it's always
bothered me that there's a case where you could still get a memory leak.

 

Suppose an element's GObjectClass.set_property() gets called while the
element is still in the NULL state.  If this property accepts a string
or some other type of heap-allocated object, the element is probably
going to create a copy or add a ref.  Now, suppose some problem occurs
and the element is disposed before ever going to the READY state.  There
will be no transition back to NULL.  Therefore, the only possibility of
deallocating the value is by overriding GstObjetClass.dispose().

 

I concede that this isn't normally an issue, since the size of any such
properties is likely to be very small and many applications will either
exit or typically repeat this sequence a limited number of times.
However, it's quite possible that some sort of automated recording
application might repeat this sequence somewhat rapidly and for an
indefinite period of time.

 

Then, there's the whole philosophical issue of avoiding even small
leaks, which turns into a very practical issue when trying to use tools
to find slightly more serious leaks.  I know you can usually work around
this, through the use of filtering, but it's inconvenient and not always
satisfactory... let's please try to avoid a flame war about this.

 

Would it be so bad for GstObjectClass and GstElementClass to at least
provide a dispose() hook?  I'm aware that I could just save the old
value & replace with my own dispose(), but something feels wrong about
having the derived type dispose of its ancestors.  It's also not a very
user-friendly way to do it, since there are numerous ways the derived
type can mess things up (i.e. not saving the old value or failing to
call it last).

 

 

Matt

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20110103/6110fb6e/attachment.htm>


More information about the gstreamer-devel mailing list