After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 593983 - dead lock in rtp session
dead lock in rtp session
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal critical
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-09-03 02:50 UTC by ric
Modified: 2010-04-16 18:44 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description ric 2009-09-03 02:50:05 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.
Comment 1 Wim Taymans 2009-09-03 17:30:43 UTC
The reconsider callback is always called after releasing the RTP_SESSION lock. Can you post a backtrace of a locked up pipeline?
Comment 2 ric 2009-09-04 02:54:27 UTC
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.
Comment 3 Tobias Mueller 2010-04-16 18:44:27 UTC
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!