[Bug 797251] webrtcbin: might leak resources when changing to NULL
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Fri Oct 5 12:02:59 UTC 2018
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.
More information about the gstreamer-bugs
mailing list