GStreamer-devel

RE: appsink python memory leak?? unref call on sample? FIXED??

Classic

List

Threaded

6 messages Options

Turmel, Frederic

RE: appsink python memory leak?? unref call on sample? FIXED??

I think I figured out what is going on. Using GST_TRACE=mem-live was an eye opener. Using the debug flag showed that there was several thousand GST_Message variable allocated along with tsdemux type variable.

****So it turns out that any message not received/read in python are accumulating forever. That is, even if you don't ask for it. TSdemux seems to be very chatty on the bus with the source I'm using. I'm getting several messages per seconds once I listen to the bus. These were eating memory.

Is this the correct behavior or that is a bug? Not sure if that is intended?

So far, by adding the following below, I did not observe memory leak. (Print was just to see what's there)
That explains why gst-launch was not exposing the problem. It is probably good practice to listen to the bus but I was not expecting this to happen.

def on_message(bus, message):
t = message.type
print t

bus = pipeline.get_bus()
bus.add_signal_watch()
bus.connect("message", on_message)

-----Original Message-----
From: gstreamer-devel [mailto:[hidden email]] On Behalf Of Turmel, Frederic
Sent: Friday, April 15, 2016 1:03 PM
To: Discussion of the development of and with GStreamer <[hidden email]>
Subject: RE: appsink python memory leak?? unref call on sample?

Yes it is already set to false. Same thing. I saw your post a while ago ;-) The thing is that even with without appsink straight to fakesink I see the issue so appsink is not the issue.

-----Original Message-----
From: gstreamer-devel [mailto:[hidden email]] On Behalf Of Tim Müller
Sent: Friday, April 15, 2016 12:36 PM
To: [hidden email]
Subject: Re: appsink python memory leak?? unref call on sample?

On Fri, 2016-04-15 at 19:09 +0000, Turmel, Frederic wrote:

Hi,

> Further test results, it looks like something is wrong with the python
> binding:
>
> gst-launch-1.0 -v udpsrc uri=udp://239.1.1.1.1:5724 buffer-
> size=50000000 ! tsdemux program-number=1 ! fakesink  NO MEMORY LEAK
> python udpsrc->tsdemux program-number=1->appsink    MEMORY LEAK python
> udpsrc->tsdemux program-number=1->fakesink   MEMORY LEAK
>
> All test using the same multicast source and property. So it looks
> like something is going with the python bindings. Any suggestion for
> the next step?
> BTW is see the same behavior on 1.6.2 on windows
>
> It is possible that tsdemux emit signals that the python binding
> cannot handle?

Out of curiosity, could you try with

fakesink enable-last-sample=false

?

If you use appsink, make sure to pull out samples.

Cheers
-Tim

--
Tim Müller, Centricular Ltd - http://www.centricular.com

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Tim Müller

Re: appsink python memory leak?? unref call on sample? FIXED??

On Sun, 2016-04-17 at 19:40 +0000, Turmel, Frederic wrote:

Hi,

> I think I figured out what is going on. Using GST_TRACE=mem-live was
> an eye opener. Using the debug flag showed that there was several
> thousand GST_Message variable allocated along with tsdemux type
> variable.
>
> ****So it turns out that any message not received/read in python are
> accumulating forever. That is, even if you don't ask for it. TSdemux
> seems to be very chatty on the bus with the source I'm using. I'm
> getting several messages per seconds once I listen to the bus. These
> were eating memory.
>
> Is this the correct behavior or that is a bug? Not sure if that is
> intended?

That is expected behaviour. Your application must handle bus messages
in some form. You can set the pipeline bus to flushing if you have a
use case where you really want to ignore them, but really any
application that's more than 5 lines of code needs to handle bus
messages.

Cheers
-Tim

--
Tim Müller, Centricular Ltd - http://www.centricular.com

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Turmel, Frederic

RE: appsink python memory leak?? unref call on sample? FIXED??

Yep, gotta learn the hard way sometimes! ;-)

Thanks
FredT

-----Original Message-----
From: gstreamer-devel [mailto:[hidden email]] On Behalf Of Tim Müller
Sent: Sunday, April 17, 2016 12:56 PM
To: [hidden email]
Subject: Re: appsink python memory leak?? unref call on sample? FIXED??

On Sun, 2016-04-17 at 19:40 +0000, Turmel, Frederic wrote:

Hi,

That is expected behaviour. Your application must handle bus messages in some form. You can set the pipeline bus to flushing if you have a use case where you really want to ignore them, but really any application that's more than 5 lines of code needs to handle bus messages.

Cheers
-Tim

--
Tim Müller, Centricular Ltd - http://www.centricular.com

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Arjen Veenhuizen

Re: appsink python memory leak?? unref call on sample? FIXED??

In reply to this post by Tim Müller

Wow, it does make sense but I never realized that this is the expected behavior. So one really has to pull all messages from the pipeline?

The gst_pipeline_set_auto_flush_bus docs [1] do indeed mention something about potential memory leaks:

It is important that all messages on the bus are handled when the automatic flushing is disabled else memory leaks will be introduced.

Doesn't this contradict your statement Tim? i interpret this as that messages are gracefully handled without any leakage when auto-flush-bus is set to TRUE (the default value).

[1] https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstPipeline.html#gst_pipeline_set_auto_flush_bus

Arjen Veenhuizen

Re: appsink python memory leak?? unref call on sample? FIXED??

On second thought, I was probably mixing up GstPipeline flushing vs GstBus flushing.
gst_bus_set_flushing [1] does mention the behavior as described by Tim:

If flushing , flush out and unref any messages queued in the bus. Releases references to the message origin objects. Will flush future messages until gst_bus_set_flushing() sets flushing to FALSE.

I think I just found the source of a memory leak in one of my apps ;)

[1] https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstBus.html

Turmel, Frederic

RE: appsink python memory leak?? unref call on sample? FIXED??

I'm glad I was not the only one :-)

-------- Original message --------
From: Arjen Veenhuizen <[hidden email]>
Date: 04/17/2016 11:29 PM (GMT-08:00)
To: [hidden email]
Subject: Re: appsink python memory leak?? unref call on sample? FIXED??

On second thought, I was probably mixing up GstPipeline flushing vs GstBus
flushing.
gst_bus_set_flushing [1] does mention the behavior as described by Tim:

> If flushing , flush out and unref any messages queued in the bus. Releases
> references to the message origin objects. Will flush future messages until
> gst_bus_set_flushing() sets flushing to FALSE.

I think I just found the source of a memory leak in one of my apps ;)

[1]
https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstBus.html

--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/RE-appsink-python-memory-leak-unref-call-on-sample-FIXED-tp4676946p4676953.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel