After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 797157 - glsinkbin: Leak if sink is not sink-ref'd in a specific order
glsinkbin: Leak if sink is not sink-ref'd in a specific order
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.14.x
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-09-17 10:04 UTC by Carlos Rafael Giani
Modified: 2018-09-17 11:00 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Carlos Rafael Giani 2018-09-17 10:04:31 UTC 
I've observed that if I sink-ref the sink I pass to glsinkbin, I have to do that in a specific order, otherwise I get GLib errors about unref'ing a discarded object.

If I do it like this, it is fine:

    g_object_set(glsinkbin, "sink", my_glsink, NULL);
    gst_object_ref_sink(my_glsink);
    [...]
    gst_object_unref(my_sink);

If I do it like this, errors occur:

    gst_object_ref_sink(my_glsink);
    g_object_set(glsinkbin, "sink", my_glsink, NULL);
    [...]
    gst_object_unref(my_sink);

It is my understanding that this should not be order dependent - at least nothing in the GLib or glsinkbin documentation hints at that. So it looks like a design flaw to me.
Comment 1 Sebastian Dröge (slomo) 2018-09-17 11:00:46 UTC 
This is a bug in your code.

With ref_sink() first you take ownership of the reference, and glsink is not going to take ownership of it (aka it takes another reference).

If you ref_sink() afterwards, then glsink will take ownership of the reference (it calls ref_sink() itself!) and you don't own it anymore (at all, you must keep another reference around otherwise!).

Check the documentation in GObject for floating references. It's all awful but that's just how it is currently :)


Note that there was a bug in glsink up to 1.14.2 related to this: 58ac815eae6ed468d1db60a54a1bd34d6324c28c and c2a7c938404a50306ef9c2048fc51c41d0c36b45 fixes it.