GNOME Bugzilla – Bug 767021
RTSP server won't be destroyed until media is pre-rolled (or 20s timeout)
Last modified: 2018-11-03 15:39:57 UTC
Created attachment 328727 [details] test case My application has an RTSP server that can be started/stopped by the user. When shutting down the server, I disconnect all clients, unref the server, and call gst_rtsp_thread_pool_cleanup() to be sure all resources has been cleaned. If a client connects just before I stop the server, it will wait for pre-roll in gst_rtsp_media_get_status(). If pre-roll never happens it will unblock on a 20s timeout. I think in the case that the client disconnects, it should unblock that condition.
Hm, looks like g_source_destroy() on the RTSP server's source fix my problem. Probably because it prevents new clients to connect while I'm trying to shutdown the server. Maybe a proper gst_rtsp_server_shutdown() method could help dealing with that case.
Actually just got a crash with that backtrace, while a thread was inside gst_rtsp_thread_pool_cleanup():
+ Trace 236291
Created attachment 328955 [details] [review] Add gst_rtsp_server_shutdown() When shutting down an RTSP server, a client could be in the process of connecting, preparing its media, etc. Most importantly, the client could be blocking waiting for the media pre-roll. To unblock that situation, the client becomes responsible to call _unprepare() on its media as soon as it reached the "preparing" state.
Context: I'm writing an (android) application that let the user start/stop sharing his webcam over RTSP. When the user stops the RTSP server I want to free all resources it takes, so I would like to call gst_rtsp_thread_pool_cleanup(). Wihtout this patch it is racy, because after calling gst_rtsp_client_close() on all existing clients, one of them could be in the middle of the process of preparing its media. For example it could be in find_media(), just before doing gst_rtsp_thread_pool_get_thread(). If gst_rtsp_thread_pool_cleanup() comes first, then the client push a thread in the pool, it crash. Also a client could be blocking in wait_preroll(), and since I'm shutting down my pipeline, chances are it will never reach the PAUSED state and thus block in waiting preroll until a 20s timeout. The patch fix that case by calling gst_rtsp_media_unprepare() on preparing medias when their client gets closed. Note that I'm *really* unsure if I'm doing it right, this is the first time I touch rtsp-server code. At least in my use case I couldn't reproduce crash/freeze anymore...
Created attachment 328984 [details] [review] Add gst_rtsp_server_shutdown() When shutting down an RTSP server, a client could be in the process of connecting, preparing its media, etc. Most importantly, the client could be blocking waiting for the media pre-roll. To unblock that situation, the client becomes responsible to call _unprepare() on its media as soon as it reached the "preparing" state.
Proposed patch uses the "preparing" signal added in the patch proposed for bug #750111
Review of attachment 328984 [details] [review]: ::: gst/rtsp-server/rtsp-media.c @@ +3011,3 @@ + if (priv->status == GST_RTSP_MEDIA_STATUS_UNPREPARED || + priv->status == GST_RTSP_MEDIA_STATUS_UNPREPARING || + priv->status == GST_RTSP_MEDIA_STATUS_ERROR) In UNPREPARING we should probably wait? And in ERROR there might still be something to shut down ::: gst/rtsp-server/rtsp-server.c @@ +1478,3 @@ + * gst_rtsp_thread_pool_cleanup(). + * + * Since: 1.10 Since: 1.12 :)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/issues/22.