[Bug 686420] New: gstqueue plugin will become deadlock in some citical cases

Thu Oct 18 20:20:58 PDT 2012

https://bugzilla.gnome.org/show_bug.cgi?id=686420
  GStreamer | gstreamer (core) | 0.11.x

           Summary: gstqueue plugin will become deadlock in some citical
                    cases
    Classification: Platform
           Product: GStreamer
           Version: 0.11.x
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: critical
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: zhangyanping210 at yahoo.com.cn
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

In my app , I create a playbin to play mms stations, such as
mms://03vl.sina.com.cn/cnr003.

And after one minute, I want to change the play station, so I called
gst_element_set_state(playbin, GST_STATE_NULL);

For most cases, it works ok,

But in some critical cases, such as When in wifi network, network is critical
bad, it will hang. I use gdb to debug, and found it is a deadlock by gstqueue.

This is the thread that I call stop cmd.
(gdb) thread 2
[Switching to thread 2 (Thread 461)]
(gdb) bt
#0  0x2aff87c4 in pthread_cond_wait@@GLIBC_2.4 ()
#1  0x2ae04010 in g_cond_wait () from
/home/zhangyp/rootfs_for_hunter/usr/lib/libglib-2.0.so.0
#2  0x2acab5f4 in gst_task_join (task=0x2df670) at gsttask.c:820
#3  0x2ac5e1fc in gst_pad_finalize (object=0xaaa6b8) at gstpad.c:614
#4  0x2ad2388c in g_object_unref () from
/home/zhangyp/rootfs_for_hunter/usr/lib/libgobject-2.0.so.0
#5  0x2ac0f2bc in gst_object_unref (object=0xaaa6b8) at gstobject.c:317
#6  0x2ac10a80 in gst_object_unparent (object=0xaaa6b8) at gstobject.c:809
#7  0x2ac3a9bc in gst_element_remove_pad (element=0x32fcf8, pad=0xaaa6b8) at
gstelement.c:804
#8  0x2ac40a80 in gst_element_dispose (object=0x32fcf8) at gstelement.c:2774
#9  0x2ad237d4 in g_object_unref () from
/home/zhangyp/rootfs_for_hunter/usr/lib/libgobject-2.0.so.0
#10 0x2ac0f2bc in gst_object_unref (object=0x32fcf8) at gstobject.c:317
#11 0x2ac1628c in gst_bin_remove_func (bin=0x32be28, element=0x32fcf8) at
gstbin.c:1503
#12 0x2ac16618 in gst_bin_remove (bin=0x32be28, element=0x32fcf8) at
gstbin.c:1561
#13 0x2ac136ac in gst_bin_dispose (object=0x32be28) at gstbin.c:529
#14 0x2ad237d4 in g_object_unref () from
/home/zhangyp/rootfs_for_hunter/usr/lib/libgobject-2.0.so.0
#15 0x2ac0f2bc in gst_object_unref (object=0x32be28) at gstobject.c:317
#16 0x31ce6784 in free_chain (chain=0x96ea00) at gstplaysink.c:610
#17 0x31cf6410 in gst_play_sink_change_state (element=0x32e32660,
transition=GST_STATE_CHANGE_READY_TO_NULL) at gstplaysink.c:4367
#18 0x2ac3fc44 in gst_element_change_state (element=0x32e32660,
transition=GST_STATE_CHANGE_READY_TO_NULL) at gstelement.c:2487
#19 0x2ac3fa70 in gst_element_set_state_func (element=0x32e32660,
state=GST_STATE_NULL) at gstelement.c:2443
#20 0x2ac3f5a0 in gst_element_set_state (element=0x32e32660,
state=GST_STATE_NULL) at gstelement.c:2344
#21 0x2ac1842c in gst_bin_element_set_state (bin=0xa99000, element=0x32e32660,
base_time=0, start_time=0, current=GST_STATE_READY, next=GST_STATE_NULL)
    at gstbin.c:2221
#22 0x2ac19c20 in gst_bin_change_state_func (element=0xa99000,
transition=GST_STATE_CHANGE_READY_TO_NULL) at gstbin.c:2526
#23 0x2ac72818 in gst_pipeline_change_state (element=0xa99000,
transition=GST_STATE_CHANGE_READY_TO_NULL) at gstpipeline.c:478
#24 0x31ce510c in gst_play_bin_change_state (element=0xa99000,
transition=GST_STATE_CHANGE_READY_TO_NULL) at gstplaybin2.c:3988
#25 0x2ac3fc44 in gst_element_change_state (element=0xa99000,
transition=GST_STATE_CHANGE_READY_TO_NULL) at gstelement.c:2487
#26 0x2ac3f068 in gst_element_continue_state (element=0xa99000,
ret=GST_STATE_CHANGE_SUCCESS) at gstelement.c:2198
#27 0x2ac3fe50 in gst_element_change_state (element=0xa99000,
transition=GST_STATE_CHANGE_PAUSED_TO_READY) at gstelement.c:2524
#28 0x2ac3fa70 in gst_element_set_state_func (element=0xa99000,
state=GST_STATE_NULL) at gstelement.c:2443
#29 0x2ac3f5a0 in gst_element_set_state (element=0xa99000,
state=GST_STATE_NULL) at gstelement.c:2344
#30 0x2aae10c8 in CLS_GSTPlayer::InnerStop (this=0xa94000, _cReason=0x2aae8058
"INTERFACE_CALL") at player/CLS_Gst_Player.cpp:772
#31 0x2aae1994 in CLS_GSTPlayer::Stop (this=0xa94000) at
player/CLS_Gst_Player.cpp:1004
#32 0x2aade550 in CLS_AVL_GST_Player_API::Stop (this=0x1508728) at
api_interface/avl_avc_gst_player_api.cpp:58
#33 0x0000a2c0 in AutoPlayingThread (_param=0x0) at autotest.cxx:330
#34 0x2aff31ec in start_thread ()  
#35 0x2b0ccee8 in clone ()

And this is the queue loop thread.

(gdb) thread 10
[Switching to thread 10 (Thread 11248)]
#0  0x2aff87c4 in pthread_cond_wait@@GLIBC_2.4 () 
#1  0x2ae04010 in g_cond_wait () from
/home/zhangyp/rootfs_for_hunter/usr/lib/libglib-2.0.so.0
#2  0x2fe00c18 in gst_queue_loop (pad=0xaaa6b8) at gstqueue.c:1132
#3  0x2acaa3a4 in gst_task_func (task=0x2df670) at gsttask.c:316
#4  0x2acab998 in default_func (tdata=0x17a048, pool=0x2f400) at
gsttaskpool.c:70
#5  0x2ade95c8 in g_thread_pool_thread_proxy () from
/home/zhangyp/rootfs_for_hunter/usr/lib/libglib-2.0.so.0
#6  0x2ade8600 in g_thread_proxy () from
/home/zhangyp/rootfs_for_hunter/usr/lib/libglib-2.0.so.0
#7  0x2aff31ec in start_thread () 
#8  0x2b0ccee8 in clone () 
#9  0x2b0ccee8 in clone ()

>From this we can see that thread 10 is waiting for thread 2 to finished. But
thread 2 is wait for adding.
 This are codes of frame 2 inThread 2 :
 while (gst_queue_is_empty (queue)) {
      GST_QUEUE_WAIT_ADD_CHECK (queue, out_flushing);
    }

I think in some cases that "g_cond_signal (&queue->item_add);"  is not called.
But I don't kown how to handle this. Hope to your help.

-- 
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.