GNOME Bugzilla – Bug 732950
deadlock after TEARDOWN
Last modified: 2014-07-11 08:01:51 UTC
Created attachment 280280 [details] backtrace The server deadlocks if it receives TEARDOWN and RTCP RR at the same time. Chack the attached backtrace. What happens basically is that RTPBin receives RTCP RR from the client which results in a call to gst_rtsp_session_touch () in the server. (pad stream lock taken, waiting for GstRTSPSession's object lock) At the same time the server is tearing down the pipeline. (GstRTSPSession's object lock taken, waiting for pad stream lock)
How about touching the session from client's own context? An idle source perhaps?
Created attachment 280286 [details] [review] touch session from clients own context May be something like this?
Created attachment 280289 [details] [review] client: touch session from client's own context proper patch
Ideally, gst_rtsp_session_filter() should not hold the lock while doing the callback. Either it should use a cookie and restart the callbacks (maybe keeping track of which ones it already did) when something changed after releasing the lock or it should make a copy of the list and work with that outside of the lock. There are more places where the filter should release the lock to avoid these kinds of deadlocks.
commit 945c93fde09b461d4b810846e2a9443f915e6507 Author: Wim Taymans <wtaymans@redhat.com> Date: Thu Jul 10 11:32:20 2014 +0200 filter: Release lock in filter functions Release the object lock before calling the filter functions. We need to keep a cookie to detect when the list changed during the filter callback. We also keep a hashtable to make sure we only call the filter function once for each object in case of concurrent modification. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=732950