[gst-devel] Gst-python object cleanup

[Edward Hervey]

Hi,

On Thu, 2009-10-29 at 02:08 -0700, Ron McOuat wrote:
> Hello Python gstreamer devs, users,
> 
> I have a long running application written in Python recording from a 
> live source which is an IP camera such as what Axis produces. The video 
> source is connected to a tee sink pad after processing and then from one 
> of the tee src pads I dynamically connect a queue, Arnout's resettime, 
> matroska mux and filesink to store the mjpeg stream. When I am done with 
> one file recording I remove the recording bin by disconnecting from the 
> tee and removing the bin from the pipeline. When I need to record again 
> I build a new recording bin and attach to the tee. The next file could 
> start recording on the next frame from the source so I use pad blocking 
> during the record bin swap.
> 
> This is all working properly for me at this point except for one thing. 
> As part of the stress testing phase I set the program to stop the 
> recording bin and create a new one once per minute. What I find is the 
> bin number and bus numbers in the recording bin detected by Python print 
> bus or print bin are increasing with each cycle and the program slowly 
> grows. After 12 hours of this the program has gone from 10 MBytes to 
> about 40 MBytes. This is enough of a memory leak to eventually cause me 
> problems. Most of the example programs I see are short lived and cleanup 
> by exiting.
> 
> When I destroy a record bin I remove it from the pipeline and set the 
> state to gst.STATE_NULL and have added code to unlink all the elements 
> inside the bin and then remove the elements from the bin. Finally I set 
> the Python variable holding the recording bin to None. Is there 
> something I missed in the cleanup process possibly equivalent to the C 
> unref on a Gobject? I am presuming the Python elements, bins and 
> pipeline etc are proxy objects that are wrappers to the C objects. I 
> have also considered that maybe I shouldn't be doing this in this manner 
> but I ran into lots of time issues trying to reuse the recording bin.
> 

  The description of how you get rid of your pipelines seems correct.

  There's only one other thing that *could* go wrong, is if you're using
a signal watch on the bus, you should remove it (i.e.
gst.Bus.remove_signal_watch()).

  If you've made sure that's correct, I'd then suggest to start tracing
the leaks at the python level. There's a couple of good articles/tools
to do that:
  http://www.lshift.net/blog/2008/11/14/tracing-python-memory-leaks
  http://mg.pov.lt/blog/hunting-python-memleaks
  And you can also have a look at how debugging memory leaks is done in
the gst-python testsuite (gst-python/tests/common.py)

    Edward

> Thanks for any suggestion.
> 
> Ron McOuat
> 
> 
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel