GNOME Bugzilla – Bug 739263
Plugin rtmp segmentation fault when stopping stream almost immediately
Last modified: 2018-11-03 13:27:58 UTC
Created attachment 289484 [details] segmentation fault of rtmp when stopping stream almost immediately Stopping rtmp stream almost immediately after start causes segmentation fault. This observed using Enigma2 and changing fast between rtmp streams. The segmentation fault is happening when Enigma2 tries to stop the stream using gst_element_set_state(m_gst_playbin, GST_STATE_NULL). Before the Enigma2 crashed the following messages appearing: eServiceMP3::stop gst_element_get_state eServiceMP3::stop gst_element_get_state PLAYING -> VOID_PENDING eServiceMP3::stop rtmp://live2.ertopen.com/live2/e600 live=1 timeout=10 eServiceMP3::stop done... eServiceMP3::m_nownext_timer->stop eServiceMP3::m_nownext_timer->stop done eServiceMP3::~eServiceMP3 eServiceMP3::destruct! eServiceMP3::eServiceMP3 eServiceMP3::construct! getResolvedKey config.mediaplayer.extraHeaders failed !! (Typo??) eServiceMP3::playbin uri=rtmp://82.192.84.30:1935/live/myStream.sdp eServiceMP3::start eServiceMP3::starting pipeline eServiceMP3::updateEpgCacheNowNext resolved to PLAY gst_element_query_position failed in getPlayPosition resolved to PLAY gst_element_query_position failed in getPlayPosition resolved to PLAY gst_element_query_position failed in getPlayPosition new service started! trying to download cuts! download failed, no cuesheet interface RemovePopup, id = ZapError [DVBCAHandler] no more services release cached channel (timer timeout) [eDVBLocalTimerHandler] remove channel 0x1794af8 [eEPGCache] remove channel 0x1794af8 [EPGC] abort caching events !! stop release channel timer eTsRemoteSource::gst_message from playbin: GstMessageStateChanged, old-state=(GstState)GST_STATE_NULL, new-state=(GstState)GST_STATE_READY, pending-state=(GstState)GST_STATE_PLAYING; eServiceMP3::state transition NULL -> READY eTsRemoteSource::gst_message from src: GstMessageStreamStatus, type=(GstStreamStatusType)GST_STREAM_STATUS_TYPE_CREATE, owner=(GstElement)"\(GstRTMPSrc\)\ source", object=(GstTask)"\(GstTask\)\ source:src"; eTsRemoteSource::gst_message from src: GstMessageStreamStatus, type=(GstStreamStatusType)GST_STREAM_STATUS_TYPE_ENTER, owner=(GstElement)"\(GstRTMPSrc\)\ source", object=(GstTask)"\(GstTask\)\ source:src"; action -> InfobarChannelSelection keyUp action -> OkCancelActions ok playing 4097:0:1:0:0:0:0:0:0:0:rtmp%3a//live2.ertopen.com/live2/e600 live=1 timeout=10:!Ert3 Open {Rtmp} eServiceMP3::stop eServiceMP3::stop gst_element_get_state eServiceMP3::stop gst_element_get_state READY -> PLAYING eServiceMP3::stop rtmp://82.192.84.30:1935/live/myStream.sdp Segmentation fault (core dumped) The backtrace from the above core dump shows the following information: (gdb) bt
+ Trace 234261
Also a log (with the last 245 lines) is attached using command GST_DEBUG_NO_COLOR=1 GST_DEBUG=*:6 enigma2 > segmentation_fault.log
Maybe this one is the same issue: https://bugzilla.gnome.org/show_bug.cgi?id=729099
Created attachment 289510 [details] [review] rtmp fix seeking and potential segfault Calling RTMP_Close from unlock can cause segfault, also it breaks seeking. Removing unlock fixes seeking. Also we are calling RTMP_Close from stop in order to properly release librtmp memory.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/184.