Reference counter when getting EOS

[Sebastian Dröge]

On Do, 2013-07-18 at 08:14 +0200, Thomas Scheuermann wrote:
> Hi Tim,
> 
> Am 17.07.2013 22:37, schrieb Tim-Philipp Müller:
> > On Wed, 2013-07-17 at 17:11 +0200, Thomas Scheuermann wrote:
> >> Am 17.07.2013 16:53, schrieb Brendan Long:
> >>> On 07/17/2013 03:41 AM, Thomas Scheuermann wrote:
> >>>> If the pipeline gets an EOS signal and I shutdown the pipeline, the
> >>>> reference counter of my decoder element is still 1.
> >>> Did you unref the pipeline? It will hold a reference to all of the
> >>> elements in it.
> >> Yes, I unref the pipeline. This is how I shutdown the pipeline.
> >> I have an event loop which is left if it gets the EOS message or if I
> >> press a key.
> >> If I press a key the everything is OK and the finalize function of my
> >> element is called.
> >> If the event loop gets the EOS message, the finalize function of my
> >> element is not called.
> >> At the moment I don't know how to dig deeper into this problem.
> >> Any help is appreciated.
> > One way would be to try and come up with a minimal test program that
> > exhibits the issue, and then share it with us. It's a bit hard to help
> > without seeing the code, other than suggesting the things that have
> > already been suggested (valgrind etc.).
> >
> > Do you do gst_element_set_state (pipeline, GST_STATE_NULL) as well when
> > shutting down? (before unreffing it)
> Yes, I set the pipeline state to GST_STATE_NULL.
> > Are you sure you unref all GstBus messages? (depends on context if
> > that's needed or not).
> Yes. each time I get a message with gst_bus_timed_pop I also unref this
> message and after leaving the event loop I also unref the bus.
> I appended the source code of my player program.
> Should I also send the source of the two elements I programmed? They use
> a proprietary library which I can't publish.

I don't see any memory leaks in the code you pasted (except maybe that
the XEvents need to be cleared somehow after usage, but I don't know the
libX11 API). Most probably the leaks will be in any of the elements.


Btw, you could consider to improve your event loop by setting up a sync
bus handler and from that send a custom X11 event... which is then taken
up by your X11 event loop. That way you never have to block the X11
event loop. Code for something like that can be found here (the
g_cond_wait() is not needed in your case of course, and it would
probably be better to queue the GstMessages in a list somewhere instead
of sending their pointers via the XEvent):
http://cgit.freedesktop.org/gstreamer/gst-plugins-gl/tree/gst-libs/gst/gl/gstglwindow_x11.c?h=0.10#n879

Alternatively you could implement a GSource that dispatches X11 events
to a GMainContext/GMainLoop. Code for that can be found here:
http://cgit.freedesktop.org/gstreamer/gst-plugins-gl/tree/gst-libs/gst/gl/x11/x11_event_source.c

But that's of course completely independent of the leaks :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130718/820cbda1/attachment.pgp>