[Bug 707611] New: rtspsrc state change always blocks when source is offline (waiting for connect timeout)

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Fri Sep 6 01:32:35 PDT 2013


https://bugzilla.gnome.org/show_bug.cgi?id=707611
  GStreamer | gst-plugins-base | git

           Summary: rtspsrc state change always blocks when source is
                    offline (waiting for connect timeout)
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: All
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: shatrov at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


gst_element_set_state (playbin, GST_STATE_PLAYING) always blocks for a pipeline
with rtspsrc when source IP is not responding, i.e. it appears to wait
synchronously for connect() to complete.

The problem appears to be because of the following lines in gstrtspsrc.c:

    case GST_STATE_CHANGE_PLAYING_TO_PAUSED:
      /* unblock the tcp tasks and make the loop waiting */
      gst_rtspsrc_loop_send_cmd (rtspsrc, CMD_WAIT, CMD_LOOP);
      /* make sure it is waiting before we send PAUSE or PLAY below */
// BUG: BLOCKS HERE
      GST_RTSP_STREAM_LOCK (rtspsrc);
      GST_RTSP_STREAM_UNLOCK (rtspsrc);

Lock/unlock pair wasn't there in older versions, and gst_element_set_state()
did not block (there was proper async state change).

Here are backtraces from my app for two threads. The first one is the
application thread which should not block, but it blocks because of this bug.
The second one is gstreamer's rtspsrc thread. Line numbers are for
gstreamer-1.0.9 release.

Application thread:
#0  __lll_lock_wait () at
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007ffff655e340 in _L_lock_928 () from /opt/moment/lib/libpthread.so.0
#2  0x00007ffff655e1d9 in __GI___pthread_mutex_lock (mutex=0x7fffe40036d0) at
pthread_mutex_lock.c:85
#3  0x00007fffeaa9a153 in gst_rtspsrc_change_state (element=0x7fffe40160b0,
transition=GST_STATE_CHANGE_PAUSED_TO_PLAYING) at gstrtspsrc.c:6725
#4  0x00007ffff5b92b2c in gst_element_change_state (element=0x7fffe40160b0,
transition=<optimized out>) at gstelement.c:2594
#5  0x00007ffff5b934af in gst_element_set_state_func (element=0x7fffe40160b0,
state=GST_STATE_PLAYING) at gstelement.c:2550
#6  0x00007ffff5b7b161 in gst_bin_element_set_state (next=GST_STATE_PLAYING,
current=GST_STATE_PAUSED, start_time=0, base_time=17345936686672174,
element=0x7fffe40160b0, bin=0x7fffe400e090) at gstbin.c:2292
#7  gst_bin_change_state_func (element=0x7fffe400e090,
transition=GST_STATE_CHANGE_PAUSED_TO_PLAYING) at gstbin.c:2594
#8  0x00007ffff03ed52c in gst_uri_decode_bin_change_state
(element=0x7fffe400e090, transition=GST_STATE_CHANGE_PAUSED_TO_PLAYING) at
gsturidecodebin.c:2580
#9  0x00007ffff5b92b2c in gst_element_change_state (element=0x7fffe400e090,
transition=<optimized out>) at gstelement.c:2594
#10 0x00007ffff5b934af in gst_element_set_state_func (element=0x7fffe400e090,
state=GST_STATE_PLAYING) at gstelement.c:2550
#11 0x00007ffff5b7b161 in gst_bin_element_set_state (next=GST_STATE_PLAYING,
current=GST_STATE_PAUSED, start_time=0, base_time=17345936686672174,
element=0x7fffe400e090, bin=0x7fffe4004110) at gstbin.c:2292
#12 gst_bin_change_state_func (element=0x7fffe4004110,
transition=GST_STATE_CHANGE_PAUSED_TO_PLAYING) at gstbin.c:2594
#13 0x00007ffff5bb0f54 in gst_pipeline_change_state (element=0x7fffe4004110,
transition=GST_STATE_CHANGE_PAUSED_TO_PLAYING) at gstpipeline.c:471
#14 0x00007ffff5b92b2c in gst_element_change_state (element=0x7fffe4004110,
transition=<optimized out>) at gstelement.c:2594
#15 0x00007ffff5b934af in gst_element_set_state_func (element=0x7fffe4004110,
state=GST_STATE_PLAYING) at gstelement.c:2550
#16 ...(the rest is application call stack with no gstreamer calls and no
external lib calls)

GStreamer rtspsrc thread:
#0  0x00007ffff627f96d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fffea16788f in g_socket_condition_timed_wait (socket=<optimized
out>, condition=<optimized out>, timeout=20000, cancellable=0x7fffe401f130,
error=0x7fffebffe918) at gsocket.c:3562
#2  0x00007fffea660af1 in do_connect (ip=<optimized out>, port=<optimized out>,
socket_out=0x7fffe0001520, timeout=0x7fffe4016338, cancellable=0x7fffe401f130)
at gstrtspconnection.c:457
#3  0x00007fffea66286a in gst_rtsp_connection_connect (conn=0x7fffe0001500,
timeout=0x7fffe4016338) at gstrtspconnection.c:725
#4  0x00007fffeaa8f601 in gst_rtsp_conninfo_connect (src=0x7fffe40160b0,
info=0x7fffe4016428, async=1) at gstrtspsrc.c:3371
#5  0x00007fffeaa987b9 in gst_rtspsrc_retrieve_sdp (async=1,
sdp=0x7fffe4016300, src=0x7fffe40160b0) at gstrtspsrc.c:5642
#6  gst_rtspsrc_open (src=0x7fffe40160b0, async=1) at gstrtspsrc.c:5809
#7  0x00007fffeaa9c305 in gst_rtspsrc_thread (src=0x7fffe40160b0) at
gstrtspsrc.c:6602
#8  0x00007ffff5bd4bef in gst_task_func (task=0x7fffe401e000) at gsttask.c:316
#9  0x00007ffff6f07b68 in g_thread_pool_thread_proxy (data=<optimized out>) at
gthreadpool.c:309
#10 0x00007ffff6f072c5 in g_thread_proxy (data=0x7fffe4006b20) at gthread.c:798
#11 0x00007ffff655bf97 in start_thread (arg=0x7fffebfff700) at
pthread_create.c:308
#12 0x00007ffff62891ed in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:114

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list