<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=Content-Type content="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 11 (filtered medium)"> <style>  </style> </head> <body lang=EN-US link=blue vlink=purple> <div class=Section1> 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.<o:p></o:p> <o:p> </o:p> 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().<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> 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).<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Matt<o:p></o:p> <o:p> </o:p> </div> </body> </html>