GNOME Bugzilla – Bug 778038
race in gstpad detected by TSan
Last modified: 2018-11-03 12:39:15 UTC
Created attachment 344717 [details] ThreadSanitizer: data race gstreamer/gst/gstpad.c:5038 in store_sticky_event This case suggested by ThreadSanitizer happens in gst_pad_query_caps_default() when pad flags are read by GST_PAD_IS_PROXY_CAPS (pad), without lock.
The possible problem here is that store_sticky_event() could change the pad flags (EOS flag) while gst_pad_query_caps_default() reads them for another flag (PROXY_CAPS). The latter can only be set once during object creation, not later. The former change at any time. The assumption in gst_pad_query_caps_default() and other places about the pad flags is that they don't change after creation, so no mutex is needed. Which is not true for the EOS, BLOCKED, FLUSHING flags at least. As access to these is all public API, we have a problem now and can't split them into separate fields anymore. I guess the only solution here would be to make GST_OBJECT_FLAG_SET()/UNSET() use atomic ops (g_atomic_int_compare_and_exchange()) and GST_OBJECT_FLAG_IS_SET() too (g_atomic_int_get()), and also the other macros. And declare that access without those macros is invalid.
I'm not sure it matters, even if partially updated, the PROXY_CAPS flag won't change.
Not specifically in this case, but for https://bugzilla.gnome.org/show_bug.cgi?id=778035 it matters possibly. And it's the same problem.
-- 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/218.