GNOME Bugzilla – Bug 650576
dynamic pipeline ref issue
Last modified: 2011-05-25 15:04:44 UTC
I have a very simple pipeline and i want to replace the fakesink in every iteration. Problems: 1. i don't understand why is the old fakesink refcount bigger than 0 (why is is not free). How can i free all resources from that element ? 2. at the end of the program i set the full pipeline to NULL state, then this comes "Trying to dispose element fakesink1, but it is in READY instead of the NULL state ...." but the fakesink1 was already replaced, set to NULL and the returned value was success and i had already removed it form the pipeline. src: http://pastebin.com/GKkqNVGb
I made another test program, witch shows that if I set for just one unlinked element to NULL state line 49., then the ref is growing up from 3 to 5. Maybe this is the critical point of the issue
Sorry the example src for Comment 1 is the same http://pastebin.com/GKkqNVGb
Since you never check the return value of gst_element_change_state(), I'm not surprised that you're having state change problems. Changing a pipeline from NULL to PLAYING almost always involved waiting for the state change to occur. Bugzilla is not the right place to ask development questions. Please use the mailing list.
could you show me ANY place where dynamic pipeline manipulation is documented? could you show me ANY place where element ref counting is documented? could you show me ANY place where element ref counting and pipeline state and/or state changes are documented? in that case it's be much easier to make such an example which can show you a clear example something which seems to be a bug. we're very carefully try to write you the simplest example, but it's almost impossible without such docs. but tomorrow we'll write you a more proper example about the same problem.
(In reply to comment #4) > could you show me ANY place where dynamic pipeline manipulation is documented? gst-plugins-base/tests/examples/dynamic/ gstreamer/docs/design/ > could you show me ANY place where element ref counting is documented? normal floating refs > could you show me ANY place where element ref counting and pipeline state > and/or state changes are documented? copy'n'paste error in question, he
so first of all it's not a documentation! do you think all developer should have to read all the sources of gstreamer? anyway here is your own example: http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/tests/examples/dynamic/sprinkle.c which is also not working. did you or anyone try this example? 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. 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. 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.
(In reply to comment #7) > so first of all it's not a documentation! do you think all developer should > have to read all the sources of gstreamer? A developer should use all the info presented to him to understand what he needs to understand. This includes documentation, source code and examples for gstreamer. > > anyway here is your own example: > http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/tests/examples/dynamic/sprinkle.c > which is also not working. did you or anyone try this example? Not lately. > > 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. > > 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. > > 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.
(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.
Keep in mind that GstMessages posted on the bus hold a ref to the element that posted them (just something that comes to mind, didn't look at the code yet).
> 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? You can use the debug log to find out who keeps a ref to those elements, as Tim said, it is likely the messages (which are unreffed when popped from the bus). In GStreamer many objects keep refs around to other objects and threads increase and decrease refcounts all the time to keep objects alive in unlocked areas. You should use a tool like valgrind to figure out what objects are leaked and then figure out where to place _unrefs(). There is nothing else that can be done. For applications the rules are very simple, look at the docs of all methods that you use and respect the refcounting rules there. The generic rules are: getters returning objects return an additional ref, methods taking an object take extra refs to the object when they need to. Exceptions are for the methods that take ownership of objects (and don't increase the refcount, you lose the ref you are holding).
So it seems that there is no bug here... if you find real leaks that are not caused by your application please reopen of file a new bug.
FWIW, just tested the gst-plugins-base/tests/examples/dynamic/sprinkle tests and they work fine for me. I have a 6core CPU and don't get any races with them.