GNOME Bugzilla – Bug 593983
dead lock in rtp session
Last modified: 2010-04-16 18:44:27 UTC
There is dead lock in gstrtpsession.c and rtpsession.c. This will influence five thread, two rtcp receiving threads, two rtcp sending threads and one control thread. The dead lock will occur under this situation, rtcp_thread() --> GST_RTP_SESSION_LOCK (rtpsession) --> rtp_session_next_timeout (rtpsession->priv->session, current_time) --> RTP_SESSION_LOCK (sess) or rtcp_thread() --> GST_RTP_SESSION_LOCK (rtpsession) --> rtp_session_on_timeout (rtpsession->priv->session, current_time, ntpnstime) --> RTP_SESSION_LOCK (sess) But the receiving sender's rtcp thread do something like this, rtp_session_process_rtcp() --> RTP_SESSION_LOCK (sess) --> rtp_session_process_bye (sess, &packet, &arrival) --> sess->callbacks.reconsider (sess, sess->reconsider_user_data) [gst_rtp_session_reconsider (RTPSession * sess, gpointer user_data) ] --> GST_RTP_SESSION_LOCK (rtpsession) see, one thread lock GST_RTP_SESSION_LOCK (rtpsession) first, then try to lock RTP_SESSION_LOCK (sess); but another thread lock RTP_SESSION_LOCK (sess) first, then try to lock GST_RTP_SESSION_LOCK (rtpsession); this will causes dead lock sooner or later. And I have encountered such a situation. The solutions, 1. This is a simple one. Add another lock in "struct _RTPSession" called inter_lock. Above five thread can't acquire their desired lock unless they acquire this inter_lock first. This will change the following function, rtcp_thread(), stop_rtcp_thread(), rtp_session_init(), rtp_session_finalize(), rtp_session_process_rtcp() 2. This is a theoretic one. Change the calling logic of this five threads. This is a big change and it needs more careful thinkings. I have not done this. Tks.
The reconsider callback is always called after releasing the RTP_SESSION lock. Can you post a backtrace of a locked up pipeline?
Sorry about that. This is the case before version 0.10.8. (I have the even older version, 0.10.4 ) So, I checked the newest version of this file. And I found that it would be wrong to unlock RTP_SESSION when you call reconsider(). If you release the lock, other thread may modify sess's state. This is why we need lock RTP_SESSION first in rtp_session_process_rtcp() thread. Can we really release the lock during rtp_session_process_rtcp() ? tks.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!