gst_debug_remove_log_function exposes a potential race condition w. LogFuncEntry's user_data/notify
Submitted by Heinrich Fink
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).