[gstreamer-bugs] [Bug 568941] New: Thread leak in libgstpulse due to problematic refcount scheme

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=568941

  GStreamer | gst-plugins-good | Ver: 0.10.10
           Summary: Thread leak in libgstpulse due to problematic refcount
                    scheme
           Product: GStreamer
           Version: 0.10.10
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: ibugs at qult.net
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


I spent the last few hours hunting down the cause of leaked threads from
applications using gstreamer for playing sound (simple playbin applications).

I suppose I've found the problem.  It lies in the way gst_pulseprobe_new() and
gst_pulseprobe_free() use g_object_ref() and g_object_unref().

Apparently a "probe" is related to an actual source or sink or mixer and so
increments its refcount upon construction and decrements it upon destruction. 
This seems indeed a sensible thing to do if probes are to exist independently
of their related source, sink or mixer.

Now the problem is that each source, sink or mixer actually owns a probe
related to itself, which means that after construction, a source, sink or mixer
has a refcount of 2 (not 1).  When the last reference to that object is
destroyed, there still is a (cyclic) reference to the probe, so the destructor
doesn't get called at all.

This would be a minor issue as long as the probe, source, sink and mixer in
this case did not spawn their own mainloop thread, which, because of the cyclic
reference and lack of proper destructor call, doesn't get terminated at all. 
Applications that make gstreamer automatically probe for pulseaudio end up with
a leaked thread each time they want to, e.g. play a sound.

This is clearly something that needs to be addressed.  I don't know the inner
workings of gstreamer well enough to decide whether simply removing the calls
to g_object_{ref,unref} in gst_pulseprobe_{new,free}() is correct.

To observe the problem, simply instantiate a playbin:

  GstElement *play = gst_element_factory_make("playbin", "play");

set it to play some wav file:

  g_object_set(G_OBJECT(play), "uri", "file:///path/to/file.wav", NULL);

and make it play several times:

  gst_element_set_state(play, GST_STATE_PLAYING);
  gst_element_set_state(play, GST_STATE_NULL);
  gst_element_set_state(play, GST_STATE_PLAYING);
  ...
  gst_element_set_state(play, GST_STATE_NULL);

and finally destroy it:

  gst_object_unref(GST_OBJECT (play));

If you have libgstpulse.so installed, you should observe an increasing number
of threads being spawned and ending up simply waiting for poll() to return.  I
my case, I'm using ALSA for output, this may be significant.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=568941.