Bug 100586

Created attachment 130705 [details] [review]
rtp: stop the transmitter before unlinking its sink (session destroy case)

Possible fix, by stopping the transmitters earlier.

(In reply to Fabrice Bellet from comment #1)
> Created attachment 130705 [details] [review] [review]
> rtp: stop the transmitter before unlinking its sink (session destroy case)

The state changes have to be sink to source, otherwise we risk a deadlock.

How do you reproduce this?

(In reply to Olivier Crête from comment #2)
> 
> How do you reproduce this?

In empathy, with an audio + video session, when both peers close the video stream only (camera button), the last client closing it can cause this error on the first client's side. This is not 100% reproducible. The visible effect for the user is that the remaining audio session also closes, while remaining open on the other user's client.

Created attachment 130716 [details]
gstreamer log messages

If this can help, it seems to me that this case is more easily reproducible, when GST_DEBUG is set to a high value (in my case, the value is set to 6), maybe some subtle scheduling differences introduced by the logging overhead.

Created attachment 131476 [details] [review]
rtp: stop the transmitter before unlinking its source

With this patch, we stop the transmitters a bit earlier but not too early compared to the previous one.

the pipeline is

transmitter-src -> funnel -> rtpbin -> substream

So your new patch is still trying to stop the transmitter-src before the funnel, but indeed this can cause a not-linked error.. I wonder if we should split the state changing and the removing steps into two separate steps.

Created attachment 131918 [details]
gstreamer pipeline dot file when reaching gstbasesrc.c:2950

Created attachment 131919 [details]
gdb backtrace matching previous dot file

The bug still exists. What looks odd to me in fs_rtp_session_dispose() is the use of the function stop_and_remove() in places where the inline comments indicate that elements are just stopped. I'd say that the transmitter_rtp_funnel is stopped (ok) and removed (not ok) too early, before the gst-src transmitters themselves are stopped. 

I have a patch that splits this function in two parts, one that just stops the elements, and one that removes the elements from the bin. Stopping the elements first, and removing them in the same order after the comment " Now they should all be stopped...". This patch works for me on this bug. Would this solution be possible ?

Created attachment 131952 [details] [review]
rtp: stop the transmitter src before unlinking the funnel

Following your comment #7, this patch splits the stop_and_remove() function and applies it to the funnel :

stop the funnel - stop the transmitters src - remove the funnel

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/farstream/farstream/issues/7.