race condition in new_manager_pad gstrtspsrc.c with freeing a DelayedLink and firing the signal no_more_pads_signal_id - gstrtspsrc.c
Submitted by Frank VanZile
Link to original bug (#779203)
Description
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.