[Bug 763496] queue: Can release serialized (ALLOCATION) query before downstream returned it

Fri Nov 25 11:30:10 UTC 2016

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

Jesper Larsen <knorr.jesper at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |knorr.jesper at gmail.com

--- Comment #10 from Jesper Larsen <knorr.jesper at gmail.com> ---
It seems like this commit could cause a deadlock. Doing some stress testing of
an application revealed a deadlock. The back trace of the two threads locked is
pasted in the bottom.

Running version 1.10.1

Thread 1101 is sending an allocation query to a queue. The thread is waiting in
gst_queue_handle_sink_query for the serialised query to be handled. As far as I
can tell, the pad stream lock is held while we wait.

Meanwhile, thread 4 is setting the pipeline state to NULL, and is waiting for
said stream lock before flushing the queue.

There are no other threads related to the pipeline running.

Reverting 722ad087338520047241a319a506e464017bf0da appears to remove the
deadlock.

Thread 1101 (Thread 0x449ff460 (LWP 7965)):
#0  0x40a0dbb0 in syscall () from /lib/libc.so.6
#1  0x403d2604 in g_cond_wait (cond=cond at entry=0x42f652b0, 
    mutex=mutex at entry=0x42f65274) at gthread-posix.c:1395
#2  0x42dfd144 in gst_queue_handle_sink_query (pad=<optimized out>, 
    parent=0x42f65078, query=<optimized out>) at gstqueue.c:1048
#3  0x40275004 in gst_pad_query (pad=pad at entry=0x42f7faa8, 
    query=query at entry=0x42f890c0) at gstpad.c:3950
#4  0x402758f4 in gst_pad_peer_query (pad=0x42f6e568, 
    query=query at entry=0x42f890c0) at gstpad.c:4082
#5  0x401c13e0 in gst_base_src_prepare_allocation (caps=0x12f878, 
    basesrc=0x42f621d8) at gstbasesrc.c:3139
#6  gst_base_src_negotiate (basesrc=0x42f621d8) at gstbasesrc.c:3283
#7  gst_base_src_loop (pad=0x42f6e568) at gstbasesrc.c:2702
#8  0x402aa82c in gst_task_func (task=task at entry=0x42f5f0d0) at gsttask.c:334
#9  0x402abafc in default_func (tdata=<optimized out>, pool=<optimized out>)
    at gsttaskpool.c:68
#10 0x403b95e4 in g_thread_pool_thread_proxy (data=<optimized out>)
    at gthreadpool.c:307
#11 0x403b9024 in g_thread_proxy (data=0x12b780) at gthread.c:784
#12 0x40925020 in start_thread () from /lib/libpthread.so.0

Thread 4 (Thread 0x42577460 (LWP 5122)):
#0  0x4092caac in __lll_lock_wait () from /lib/libpthread.so.0
#1  0x40927588 in pthread_mutex_lock () from /lib/libpthread.so.0
#2  0x42dfe2e8 in gst_queue_sink_activate_mode (parent=0x42f65078, 
    pad=0x42f7faa8, mode=<optimized out>, active=<optimized out>)
    at gstqueue.c:1683
#3  gst_queue_sink_activate_mode (pad=0x42f7faa8, parent=0x42f65078, 
    mode=<optimized out>, active=<optimized out>) at gstqueue.c:1658
#4  0x4027255c in activate_mode_internal (pad=pad at entry=0x42f7faa8, 
    parent=0x40223110 <bin_bus_handler>, parent at entry=0x42f65078, 
    mode=mode at entry=GST_PAD_MODE_PUSH, active=active at entry=0) at gstpad.c:1178
#5  0x40273180 in gst_pad_set_active (pad=pad at entry=0x42f7faa8, active=0)
    at gstpad.c:1079
#6  0x4024d600 in activate_pads (vpad=<optimized out>, ret=0x425763f0, 
    active=0x4257642c) at gstelement.c:2783
#7  0x40261304 in gst_iterator_fold (it=it at entry=0x42f6af88, 
    func=func at entry=0x4024d5e4 <activate_pads>, ret=ret at entry=0x425763f0, 
    user_data=user_data at entry=0x4257642c) at gstiterator.c:616
#8  0x4024d940 in iterator_activate_fold_with_resync (
    iter=iter at entry=0x42f6af88, user_data=0x4257642c, 
    user_data at entry=0x42576424, func=0x4024d5e4 <activate_pads>)
    at gstelement.c:2807
#9  0x4024fe1c in gst_element_pads_activate (element=element at entry=0x42f65078, 
    active=1076178988) at gstelement.c:2851
#10 0x402501a0 in gst_element_change_state_func (
    element=element at entry=0x42f65078, 
    transition=transition at entry=GST_STATE_CHANGE_PAUSED_TO_READY)
    at gstelement.c:2917
#11 0x4025284c in gst_element_change_state (element=element at entry=0x42f65078, 
    transition=transition at entry=GST_STATE_CHANGE_PAUSED_TO_READY)
    at gstelement.c:2695
#12 0x402533a8 in gst_element_set_state_func (element=0x42f65078, 
    state=<optimized out>) at gstelement.c:2649
#13 0x40252558 in gst_element_set_state (element=element at entry=0x42f65078, 
    state=GST_STATE_READY, state at entry=GST_STATE_VOID_PENDING)
    at gstelement.c:2550
#14 0x4022c15c in gst_bin_element_set_state (next=<optimized out>, 
    current=<optimized out>, start_time=0, base_time=1, element=0x42f65078, 
    bin=<optimized out>) at gstbin.c:2613
#15 gst_bin_change_state_func (element=0x42f031b0, transition=1123438776)
    at gstbin.c:2955
#16 0x4027c998 in gst_pipeline_change_state (element=element at entry=0x42f031b0, 
    transition=transition at entry=GST_STATE_CHANGE_PAUSED_TO_READY)
    at gstpipeline.c:499
#17 0x4025284c in gst_element_change_state (element=0x42f031b0, 
    element at entry=0x40317c6c <_gst_debug_min>, 
    transition=GST_STATE_CHANGE_PAUSED_TO_READY, transition at entry=1076985668)
    at gstelement.c:2695
#18 0x40252f20 in gst_element_continue_state (
    element=0x40317c6c <_gst_debug_min>, element at entry=0x42f031b0, 
    ret=ret at entry=GST_STATE_CHANGE_NO_PREROLL) at gstelement.c:2403
#19 0x402528d8 in gst_element_change_state (element=element at entry=0x42f031b0, 
    transition=transition at entry=GST_STATE_CHANGE_PLAYING_TO_PAUSED)
    at gstelement.c:2741
#20 0x402533a8 in gst_element_set_state_func (element=0x42f031b0, 
    state=<optimized out>) at gstelement.c:2649
#21 0x40252558 in gst_element_set_state (element=0x42f031b0, 
    state=state at entry=GST_STATE_NULL) at gstelement.c:2550

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