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

[Frank VanZile]

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.


Gstreamer Version: 1.10.3
OS: MAC (OSX)
Pipeline:  rtspsrc debug=false timeout=0 location=%@ latency=%d 
ntp-sync=false drop-on-latency=true udp-reconnect=true 
do-retransmission=false max-rtcp-rtp-time-diff=-1 name=rtsp ! 
rtph264depay name=x2 ! h264parse name=x3 ! vtdec name=x4 ! 
autovideosink  name=prim