GNOME Bugzilla – Bug 751440
gst_debug_remove_log_function exposes a potential race condition w. LogFuncEntry's user_data/notify
Last modified: 2018-11-03 12:28:09 UTC
In gst/gstinfo.c, gst_debug_remove_with_compare_func copies and leaks the list __log_functions in order to avoid locking in gst_debug_log_valist to make it thread-safe. However, gst_debug_remove_with_compare_func also executes the destroy-notifier on the LogFuncEntry's user_data, and this could actually still be used by a logging action while it is deleted. To make this fully thread-safe, we could use a reader/writer lock ("shared" mutex), where the gst_debug_log_valist acquires a read-lock, and the add/remove functions of the debug handler acquire a write-lock. With the current implementation, we should at least document that gst_debug_remove_log_function and gst_debug_remove_log_function_by_date are not thread-safe (with respect to the user-data of installed log functions).
Created attachment 306163 [details] [review] Document that removing loggers is racy after gst_init
-- 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/gstreamer/issues/117.