GNOME Bugzilla – Bug 765481
UI deadlock when the fsrtp conference is freeed while in preroll
Last modified: 2018-05-22 19:10:05 UTC
Hi! I encounter sometimes a deadlock in the UI when the fs rtp session is freeed, when executing call_state_changed_cb() with TP_CALL_STATE_ENDED state. This happens when the pipeline is in preroll state, and one sink is waiting on the preroll condition. when the tp_clear_object() function is invoked in this state, the fs_rtp_stream_dispose() function deadlocks on the stream_lock mutex of a pad previously locked on the path leading to the sink waiting on preroll. I attach a gdb trace showing this case. The preroll condition should be signaled *later* when the whole pipeline is set to GST_STATE_NULL in empathy_call_window_reset_pipeline(), this is what happens in the second gdb trace provided. This second trace shows a working situation. Setting stopping the pipeline earlier in on_call_state_changed_cb() seems to workaround the locking issue.
Created attachment 326608 [details] gdb trace showing the deadlock situation thread 1 is locked on post_activate() for pad=0x7fc9b8031d90, called from on_call_state_changed_cb(). this pad is already locked in thread 23, frame #35, at the beginning of function gst_pad_chain_data_unchecked(), this thread in waiting on the sink preroll condition.
Created attachment 326609 [details] gdb trace of a working situation the preroll condition is signaled when the base sink is flusing, while the pipeline is stopped in empathy_call_window_reset_pipeline().
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME'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.gnome.org/GNOME/empathy/issues/871.