[gstreamer-bugs] [Bug 322628] New: gst_value_intersect(), _register_intersect_func() etc. are not thread-safe

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=322628
 GStreamer | gstreamer (core) | Ver: HEAD CVS

           Summary: gst_value_intersect(), _register_intersect_func() etc.
                    are not thread-safe
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: t.i.m at zen.co.uk
         QAContact: gstreamer-bugs at lists.sourceforge.net
                CC: all-bugs at bugzilla.gnome.org


The following functions use g_array_index():

  gst_value_can_union()
  gst_value_union()
  gst_value_can_intersect()
  gst_value_intersect()
  gst_value_subtract()

while the following functions use g_array_append()

  gst_value_register_union_func()
  gst_value_register_intersect_func()
  gst_value_register_subtract_func()

all accessing arrays with file scope unprotected by mutexes. 

gst_value_register_foo_func() might trigger a g_realloc() within GLib; if at the
same time a gst_value_foo() operation is going on in another thread, the memory
it accesses from g_array_index() has become invalid and bad things will happen.

This is a bit of a theoretical problem, but IMHO we should either make things
thread-safe or document the thread unsafety of these functions.

Of course this is not a problem for GStreamer itself. In GStreamer, all GstValue
stuff is registered from gst_init(), and at that point we don't need to worry
about thread-safety yet.

However, the GstValue API is public, and any application or plugin or library
built on top of GStreamer is free to use it, and there is AFAICS no way to
guarantee for these users that they can register their stuff in a context where
thread-safety is not an issue (e.g. in case of a plugin loaded later).

Locking might be undesirable for performance reasons in functions like these,
but given the context they are usually used from (gst_caps_*) I find it hard to
believe that the performance impact of locking is actually significant here
(pure guesswork of course).

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