GStreamer memory leak after pipeline restart

[Nicolas Dufresne]

Le vendredi 26 avril 2019 à 06:05 -0500, Stivius a écrit :
> I had several video playing concurrently in my original app (started at 300
> MiB and increased to 1 GiB usage after a couple of restarts). They should be
> restarted (unref the whole pipeline and create again) every N minutes. After
> the 3rd or the 4th restart, the memory consumption was increased up to 6-7
> GiB and drop back again to 1 GiB. It happened several times. So it's not a
> typical memory leak but I don't know why it started at 300 MiB, increased to
> 1 GiB and fluctuated between 6-7 and 1 GiB.
> 
> So I decided to create 2 simple tests. 
> 
> *The 1st test:*
> What I was testing: simple video 114.8 MiB length and duration almost 5
> minutes.
> What was the problem: memory usage starts at 62.2 MiB and increased to 88
> MiB after 1st play. When the video was reloaded and pipeline restarted
> (unrefed and created again) then memory usage remained 88 MiB and continue
> increasing up to 105 MiB where it remained stable for the rest of testing
> time.
> 
> 
> 
> *The 2nd test* is not even related to the pipeline but to GstDiscoverer
> which I was using as well in my original app.
> What I was testing: simple GstDiscoverer plugin
> What was the problem: memory started at 19.2 MiB and increased to 100 MiB
> where remained stable for the rest of testing time;
> 
> 
> 
> 
> Conclusion: it's not a real memory leak but I want to know why it
> continuously increasing memory to some "magic bound". In the original app,
> it was even weirder because it was fluctuating between 1 GiB and 6-7 GiB
> event if I unrefed all the resources.
> 
> *Maybe, GStreamer uses some internal pool or cache that it doesn't free even
> after pipeline unref. Any suggestions?
> *

There is bunch of pools but they are limited in size by default. There
is tools to help you find out what is going on. It's a bit hacky
(implementation whise) but the leak tracer can be triggered with USR1
USR2 unix signal to dump the allocate GObject and GstMiniObject, this
often is enough to find out the source of the run-time leak (if I can
qualify it this way). You'll have to read the leak tracer code for more
detail, this is under documented atm and I don't remember all the
details. There is also blog post around.

If that is not working, you can use valgrind massif tool. Again, you'll
have to search how to use that, I'm not that familiar with it.

> 
> 
> 
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel