[Bug 755329] Race condition around finish_unprepare

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=755329

--- Comment #8 from Kseniya Vasilchuk <vasilchukkseniia at gmail.com> ---
Created attachment 338497
  --> https://bugzilla.gnome.org/attachment.cgi?id=338497&action=edit
GST_RTSP_MEDIA_STATUS_UNPREPARING status check inside finish_unprepare

> (In reply to Nikita Bobkov from comment #5)
> > Created attachment 333562 [details] [review] [review]
> > finish_unprepare race condition fix 2
> 
> Fix the problem, at least in my case.

Ok, it wasn't the solution. The problem of gst_rtsp_media_set_status moving is
that it makes the sigfault because of the double source removing.
I suggest to do a status check to GST_RTSP_MEDIA_STATUS_UNPREPARING after lock
inside "finish_unprepare".

Why is GST_RTSP_MEDIA_STATUS_UNPREPARING instead of
GST_RTSP_MEDIA_STATUS_UNPREPARED like was suggested in comment #1?
Because, besides unprepare functions, we have "gst_rtsp_media_prepare"
function. And it is possible that we will have following case:

1) "finish_unprepare" from "default_handle_message" happens and changes status
to GST_RTSP_MEDIA_STATUS_UNPREPARED.
2) we go to "gst_rtsp_media_unprepare" and if the status is
GST_RTSP_MEDIA_STATUS_UNPREPARED (it is) then go to "finish_unprepare".
3) we have unlock mutex inside "finish_unprepare".
4) we go to "gst_rtsp_media_prepare" and lock the mutex, then we check for
GST_RTSP_MEDIA_STATUS_UNPREPARED (still it is) and set status to
GST_RTSP_MEDIA_STATUS_PREPARING, unlock the mutex.
5) we lock back the mutex inside "finish_unprepare" (see (3)) and check for
GST_RTSP_MEDIA_STATUS_UNPREPARED (it's already GST_RTSP_MEDIA_STATUS_PREPARING 
(4)) and make some unpreparing things with working media.
6) we have a sigfault and many CRITICAL errors before it.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.