[Bug 650576] dynamic pipeline ref issue

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Fri May 20 06:29:43 PDT 2011


https://bugzilla.gnome.org/show_bug.cgi?id=650576
  GStreamer | gstreamer (core) | 0.10.35

--- Comment #9 from Levente Farkas <lfarkas at lfarkas.org> 2011-05-20 13:29:38 UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> > in the remove_source function if you print the refcount values for the
> > info->element its:
> > 1 (before gst_element_set_state)
> > 5 (after gst_element_set_state)
> > 4 (after gst_bin_remove)
> > what's more info is freed at the end of do function while it's contains
> > info->element which's ref count still not 0.
> 
> That's possible.

do you mean: that's possible a bug or that's possible good in this way?

> > so either this example is still buggy or gstreamer is buggy as it's use ref
> > count and element addition, state changes or anything else.
> > anyway why recount is change from 1 to 5? what is the 4 reference? is it
> > documented anywhere? we'd be happy to read and understand the behaviour.
> 
> You can read up on how refcounting works here:
> http://en.wikipedia.org/wiki/Reference_counting
> There is really no magic going on in GStreamer here and you should be able to
> understand how it works.

we know how reference counting is working:-) we just don't know how and when
reference counting works in gstreamer?
eg in the above case why gst_element_set_state rise it from 1 to 5? who hold in
this case those 4 reference and who can release it? what is the proper way?

> > of course this behaviour result a huge memory leak in case of frequent element
> > addition and removing or eg in a long running service.
> > so imho it's serious bug in gstreamer.
> 
> Maybe it isn't.

what does this means?

ok. i describe our original problem:
we use one pipeline to record video from an ip camera and every our like to
open a new file which store the video (without loose any frame!). so in every
hour we podlock the filesink and create a new filesink drop the old filesink
and release the padlock. and this process create a memleak. so we create a test
when we create a new file in evey 15 sec which create a much faster memleak.
and we're not able to find and docs or info about how this should have to do in
the proper way. that's why we wrote this simple example and we find gstreamer
leak even in this case and even in the gstreamer's example.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list