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 _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Bugs around rtspsrc can be files at bugs.gnome.org, under product
GStreamer, component gst-plugisn-good. Please make sure to test with the most recent version of GStreamer in case this bug was already fixed, Le jeudi 23 février 2017 à 13:00 -0800, Frank VanZile a écrit : > 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 > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel signature.asc (188 bytes) Download Attachment |
Free forum by Nabble | Edit this page |