[Bug 779203] New: race condition in new_manager_pad gstrtspsrc.c with freeing a DelayedLink and firing the signal no_more_pads_signal_id - gstrtspsrc.c

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779203

            Bug ID: 779203
           Summary: race condition in new_manager_pad gstrtspsrc.c with
                    freeing a DelayedLink and firing the signal
                    no_more_pads_signal_id - gstrtspsrc.c
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Mac OS
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: frank at fvanzile.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

if someone can specify how they want this fixed.  ref counting, adding a lock
or soemthing else.  i might have time to make the fix.


race condition in new_manager_pad gstrtspsrc.c with freeing a 
DelayedLink and firing the signal no_more_pads_signal_id

DelayedLink sets up two signal handlers
     no_more_pads_signal_id
     pad_added_signal_id

I see two different threads going new_manager_pad at the same
time.   
the problem is

line 2587: gst_element_add_pad (GST_ELEMENT_CAST (src), stream-
> srcpad); 
will
     1) calls gst_parse_found_pad will disconnect the signal
handlers 
for no_more_pads_signal_id and pad_added_signal_id
     2) calls gst_parse_free_delayed_link to free the DelayedLink

line 2593: gst_element_no_more_pads (GST_ELEMENT_CAST (src));
     1) will fire the no_more_pads_signal_id single handler for the 
DelayedLink and calls gst_parse_no_more_pad to log DelayedLink
information

So, based on random chance one thread is in gst_element_no_more_pads
and 
is processing the signal for no_more_pads_signal_id.
Then another thread is in gst_element_add_pad, disconnects the
signal 
handlers (which the signal is already being processed by the first 
thread) and then g_slice_free the DelayedLink struct.  But, thread 1
is 
processing the signal and calling gst_parse_no_more_pad which is
them 
trying to use the DelayedLink struct that thread 2 just
freed.  Memory 
Exception.

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