GNOME Bugzilla – Bug 612406
[PATCH] rtspsrc: Race condition
Last modified: 2013-06-25 12:24:56 UTC
Created attachment 155720 [details] gstreamer log showing the race condition and abort. There is a race condition in rtspsrc in conjunction with using the timeout property and changing the state of the element to NULL. Attaching a gstreamer log showing an abort cause by this. In this log the rtspsrc is set to receive data over multicast with a timeout of 10 seconds. Due to a router on the way not letting the multicast traffic pass it times out (timestamp 0:00:31.145568704). Hence the rtspsrc begins shutting down. Very soone afterwards, our controlling application who has set up a similar timeout of 10 seconds times out and gets scheduled before the rtspsrc is done(at 0:00:31.196563630). It then sets the pipeline to NULL in the call to media_streamer_disconnect_nolock(). This seems to trigger a parallel state change on rtspsrc and confuses it completely, ending with the Gstreamer-CRITICAL. rtspsrc doesnt seem MT safe...
Created attachment 157491 [details] [review] Patch for rtspsrc Attaching a patch that fixes this problem for us. Contains both a few changes suggested by Wim Taymans and some changes for this special case. Patch is only tested in our environment.
Created attachment 157494 [details] Another problem still remains; log excerpt Above patch didnt fix everything. Got this crash after a while. Still a race in there.
Wim? Are these patches good and do you have an idea how to fix the remaining race?
Looks like at least parts of the patch may still apply (did not check log or if it's needed)
Is this still a problem? many things changes, state changes are not done async etc..