[gst-devel] Gst-python object cleanup
bilboed at gmail.com
Thu Oct 29 10:54:05 CET 2009
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.
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:
And you can also have a look at how debugging memory leaks is done in
the gst-python testsuite (gst-python/tests/common.py)
> 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!
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
More information about the gstreamer-devel