[Bug 797251] webrtcbin: might leak resources when changing to NULL

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=797251

Matthew Waters (ystreet00) <ystreet00 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO
                 CC|                            |ystreet00 at gmail.com

--- Comment #7 from Matthew Waters (ystreet00) <ystreet00 at gmail.com> ---
If this is a hang, a backtrace is most useful. A debug log would also be
useful.

(In reply to Aleix Conchillo Flaqué from comment #6)
> (In reply to Aleix Conchillo Flaqué from comment #4)
> 
> > That is, nothing prevents the idle sources to keep executing when the
> > element changes state to NULL. In my app I have a ref to the pipeline and a
> > ref to the webrtcbin element. I set the pipeline to NULL and I unref it
> > next. At this point I would expect GST_OBJECT_REFCOUNT_VALUE for the
> > webrtcbin element to always be 1 (my copy should be the last one), but it's
> > not.

Nothing guarantees that your reference is the last one so you can't use that as
a metric.

> Also, my app has it's own main loop where I run the gstreamer pipelines.
> After setting the pipelines to NULL I stop my main loop. At this point I
> have no idea what happens with the webrtcbin idle sources. Since webrtcbin
> has its own main loop they should still be executing.

Correct, they would execute normally.

> With own of my prints I have seen an idle source blocking here:
> 
> _create_transport_channel (...)
> {
>   ...
>   gst_element_sync_state_with_parent (GST_ELEMENT (ret->send_bin));
>   gst_element_sync_state_with_parent (GST_ELEMENT (ret->receive_bin));
> 
> My guess is that once the pipeline is set to NULL (and the idle source still
> running), this will just be blocked somewhere. But since it's an idle source
> and it's running on its own main context it will not affect the main
> application.

It should not be blocked though and a backtrace of all the threads and a debug
log is definitely needed to figure out what else might be going on.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.