[Bug 752623] New: concat: Test pipeline with uridecodebin and concat freezes sometimes when setting pipeline to state NULL

Mon Jul 20 03:14:43 PDT 2015

https://bugzilla.gnome.org/show_bug.cgi?id=752623

            Bug ID: 752623
           Summary: concat: Test pipeline with uridecodebin and concat
                    freezes sometimes when setting pipeline to state NULL
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: dv at pseudoterminal.org
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 307744
  --> https://bugzilla.gnome.org/attachment.cgi?id=307744&action=edit
Test program showing the freeze

I stumbled upon a curious problem the other day. I set up a pipeline with a
concat element, a sink (can be a fakesink, but sync is set to TRUE), two
uridecodebins, two identity elements. The link order goes like this:

uridecodebin1 *-> identity1 -> concat  uridecodebin2 *-> identity2 -> concat 
concat -> sink

The uridecodebin-identity connections are marked with a * , since these are not
linked immediately. Instead, they are linked in the decodebin's pad-added
callback. Only audio is linked.

This is a simple pipeline. Once uridecodebin1 is done playing, uridecodebin2
would take over. Works fine.

However, if I set the pipeline state to NULL immediately after having set it to
PLAYING, it sometimes hangs in the gst_element_set_state(pipeline,
GST_STATE_NULL); call. It might take quite a while for this deadlock to appear,
but it eventually does. A quick check with gdb shows this:

#1  0x00007ffff7328672 in _L_lock_953 () from
/lib/x86_64-linux-gnu/libpthread.so.0
#2  0x00007ffff73284da in __GI___pthread_mutex_lock (mutex=0x7fffdc00f5b0) at
../nptl/pthread_mutex_lock.c:114
#3  0x00007ffff7b120ff in post_activate (pad=0x8033d0,
new_mode=GST_PAD_MODE_NONE) at gstpad.c:999
#4  0x00007ffff7b12a09 in gst_pad_activate_mode (pad=0x8033d0,
mode=GST_PAD_MODE_PUSH, active=0) at gstpad.c:1187
#5  0x00007ffff7b01edf in gst_ghost_pad_activate_push_default
(pad=0x7fffdc008870, parent=0x7fa500, active=0) at gstghostpad.c:379
#6  0x00007ffff7b0226b in gst_ghost_pad_activate_mode_default
(pad=0x7fffdc008870, parent=0x7fa500, mode=GST_PAD_MODE_PUSH, active=0) at
gstghostpad.c:442
#7  0x00007ffff7b129ef in gst_pad_activate_mode (pad=0x7fffdc008870,
mode=GST_PAD_MODE_PUSH, active=0) at gstpad.c:1180
#8  0x00007ffff7b1247f in gst_pad_set_active (pad=0x7fffdc008870, active=0) at
gstpad.c:1064
#9  0x00007ffff7aca865 in activate_pads (vpad=0x7fffffffcd10,
ret=0x7fffffffcd60, active=0x7fffffffcda4) at gstbin.c:2368
#10 0x00007ffff7b08d52 in gst_iterator_fold (it=0x7e8140, func=0x7ffff7aca826
<activate_pads>, ret=0x7fffffffcd60, user_data=0x7fffffffcda4) at
gstiterator.c:614
#11 0x00007ffff7aca8e9 in iterator_activate_fold_with_resync (iter=0x7e8140,
user_data=0x7fffffffcda4) at gstbin.c:2387
#12 0x00007ffff7aca9d2 in gst_bin_src_pads_activate (bin=0x7fa500, active=0) at
gstbin.c:2421
#13 0x00007ffff7acbb08 in gst_bin_change_state_func (element=0x7fa500,
transition=GST_STATE_CHANGE_PAUSED_TO_READY) at gstbin.c:2611
#14 0x00007ffff5acc251 in gst_decode_bin_change_state (element=0x7fa500,
transition=GST_STATE_CHANGE_PAUSED_TO_READY) at gstdecodebin2.c:4953
#15 0x00007ffff7af95c3 in gst_element_change_state (element=0x7fa500,
transition=GST_STATE_CHANGE_PAUSED_TO_READY) at gstelement.c:2604
#16 0x00007ffff7af9473 in gst_element_set_state_func (element=0x7fa500,
state=GST_STATE_READY) at gstelement.c:2560
#17 0x00007ffff7af9061 in gst_element_set_state (element=0x7fa500,
state=GST_STATE_READY) at gstelement.c:2461
#18 0x00007ffff7aca6ae in gst_bin_element_set_state (bin=0x7e22d0,
element=0x7fa500, base_time=0, start_time=0, current=GST_STATE_PAUSED,
next=GST_STATE_READY) at gstbin.c:2328
#19 0x00007ffff7acbd1a in gst_bin_change_state_func (element=0x7e22d0,
transition=GST_STATE_CHANGE_PAUSED_TO_READY) at gstbin.c:2676
#20 0x00007ffff5ad4aa7 in gst_uri_decode_bin_change_state (element=0x7e22d0,
transition=GST_STATE_CHANGE_PAUSED_TO_READY) at gsturidecodebin.c:2752
#21 0x00007ffff7af95c3 in gst_element_change_state (element=0x7e22d0,
transition=GST_STATE_CHANGE_PAUSED_TO_READY) at gstelement.c:2604
#22 0x00007ffff7af9473 in gst_element_set_state_func (element=0x7e22d0,
state=GST_STATE_READY) at gstelement.c:2560
#23 0x00007ffff7af9061 in gst_element_set_state (element=0x7e22d0,
state=GST_STATE_READY) at gstelement.c:2461
#24 0x00007ffff7aca6ae in gst_bin_element_set_state (bin=0x6826a0,
element=0x7e22d0, base_time=0, start_time=0, current=GST_STATE_PAUSED,
next=GST_STATE_READY) at gstbin.c:2328
#25 0x00007ffff7acbd1a in gst_bin_change_state_func (element=0x6826a0,
transition=GST_STATE_CHANGE_PAUSED_TO_READY) at gstbin.c:2676
#26 0x00007ffff7b23b6b in gst_pipeline_change_state (element=0x6826a0,
transition=GST_STATE_CHANGE_PAUSED_TO_READY) at gstpipeline.c:499
#27 0x00007ffff7af95c3 in gst_element_change_state (element=0x6826a0,
transition=GST_STATE_CHANGE_PAUSED_TO_READY) at gstelement.c:2604
#28 0x00007ffff7af9473 in gst_element_set_state_func (element=0x6826a0,
state=GST_STATE_NULL) at gstelement.c:2560
#29 0x00007ffff7af9061 in gst_element_set_state (element=0x6826a0,
state=GST_STATE_NULL) at gstelement.c:2461

I am using the most recent git master (I checked the repositories out
yesterday). I also managed to replicate the problem with a small test case,
which I attached. It requires one argument, a URI to an audio file. (It has to
be an URI, so use file:// ). Most of the time, the deadlock occurs within 30
seconds. I was most successful at replicating it by playing Ogg Vorbis files.

Now, perhaps I am using the uridecodebins incorrectly. I noticed in the playbin
code that when shutting down, the playbin is applying all sorts of state locks
to the uridecodebin elements and flags to early-exit pad-added callbacks, so
maybe I need some of that logic here too.

Also, in uridecodebin, I set async-handling to TRUE, since I need that in my
main application to avoid PAUSED states "leaking" into the main pipeline and
disrupting gapless playback. I noticed that playbin does that differently; it
checks for ASYNC_START and ASYNC_DONE messages, and if these came from
uridecodebins, the messages are discarded. Not sure if this is the better
approach, or if async-handling=TRUE is at least partially responsible for the
problems. I tried running it with async-handling=FALSE, and it didn't change
much - the deadlocks still happened.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.