<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Setting the pipeline to NULL and then unreffing it is the correct way (assuming there’s not something else in your code).<div><br></div><div>The leak may very easily be in one of the elements in the pipeline. This is specially true if you are using third party plug-ins. I recommend trying the super useful “leaks” tracer. Something like:</div><div><br></div><div>GST_TRACER=leaks GST_DEBUG=GST_TRACER:7 ./app</div><div><br></div><div>Additionally, here’s a guide on how to analyze a GStreamer application with Valgrind (it can be tricky):</div><div><br></div><div><a href="https://developer.ridgerun.com/wiki/index.php?title=How_to_Analyze_Gstreamer_with_Valgrind">https://developer.ridgerun.com/wiki/index.php?title=How_to_Analyze_Gstreamer_with_Valgrind</a></div><div><br></div><div><div dir="ltr">Michael</div><div id="AppleMailSignature" dir="ltr">www.ridgerun.com</div><div dir="ltr"><br><blockquote type="cite">On 17 Jan 2021, at 11:16, jackBuffington <jbuffington@redzone.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span>I have a program that I have written that repeatedly starts and stops some</span><br><span>relatively complex pipelines. Everything is working but in my final</span><br><span>testing, I have found that around the 38th time I do this, the program</span><br><span>becomes unstable and crashes. When I use htop (I'm working in linux) to</span><br><span>look at system resources, it seems that every time I launch a new pipeline,</span><br><span>all of the gstreamer threads that are spawned use just a little more memory. </span><br><span>I'm assuming that this isn't an issue with Gstreamer but rather with how I</span><br><span>am using it. </span><br><span></span><br><span>When starting pipelines, I am creating my pipeline in C++ using</span><br><span>gst_parse_launch(). I then set it to the READY state and then the PLAY</span><br><span>state. When shutting down, I was sending an EOS and then setting the</span><br><span>pipeline to NULL and then calling gst_object_unref (). </span><br><span></span><br><span>Suspecting that this isn't quite the correct way even though it is what is</span><br><span>shown in all of the demo code that I have seen, I tried sending an EOS and</span><br><span>then setting its state to PAUSED then READY then NULL but that seems to</span><br><span>leave straggler elements still running and I can only launch and kill four</span><br><span>pipelines before the program fails. I've also tried sending an EOS then</span><br><span>READY then NULL but only get about five pipelines before it fails. </span><br><span></span><br><span>I've also tried gst_deinit() followed by a new gst_init thinking that if I</span><br><span>blow away all Gstreamer stuff entirely then that really ought to clear up</span><br><span>the problem but that doesn't work past the first pipeline. </span><br><span></span><br><span>So... What is the correct way to shut down a pipeline to not have the</span><br><span>memory issue that I am seeing? Have any of you experienced this? I would</span><br><span>think that it would be a fairly common thing to be switching the pipelines</span><br><span>that are being used as a program runs. </span><br><span></span><br><span></span><br><span></span><br><span>--</span><br><span>Sent from: http://gstreamer-devel.966125.n4.nabble.com/</span><br><span>_______________________________________________</span><br><span>gstreamer-devel mailing list</span><br><span>gstreamer-devel@lists.freedesktop.org</span><br><span>https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</span><br></div></blockquote></div></body></html>