After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 686420 - gstqueue plugin will become deadlock in some citical cases
gstqueue plugin will become deadlock in some citical cases
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.11.x
Other Linux
: Normal critical
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-10-19 03:20 UTC by zhangyanping
Modified: 2012-12-03 06:35 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description zhangyanping 2012-10-19 03:20:53 UTC
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 pthread_cond_wait
  • #1 g_cond_wait
    from /home/zhangyp/rootfs_for_hunter/usr/lib/libglib-2.0.so.0
  • #2 gst_task_join
    at gsttask.c line 820
  • #3 gst_pad_finalize
    at gstpad.c line 614
  • #4 g_object_unref
    from /home/zhangyp/rootfs_for_hunter/usr/lib/libgobject-2.0.so.0
  • #5 gst_object_unref
    at gstobject.c line 317
  • #6 gst_object_unparent
    at gstobject.c line 809
  • #7 gst_element_remove_pad
    at gstelement.c line 804
  • #8 gst_element_dispose
    at gstelement.c line 2774
  • #9 g_object_unref
    from /home/zhangyp/rootfs_for_hunter/usr/lib/libgobject-2.0.so.0
  • #10 gst_object_unref
    at gstobject.c line 317
  • #11 gst_bin_remove_func
    at gstbin.c line 1503
  • #12 gst_bin_remove
    at gstbin.c line 1561
  • #13 gst_bin_dispose
    at gstbin.c line 529
  • #14 g_object_unref
    from /home/zhangyp/rootfs_for_hunter/usr/lib/libgobject-2.0.so.0
  • #15 gst_object_unref
    at gstobject.c line 317
  • #16 free_chain
    at gstplaysink.c line 610
  • #17 gst_play_sink_change_state
    at gstplaysink.c line 4367
  • #18 gst_element_change_state
    at gstelement.c line 2487
  • #19 gst_element_set_state_func
    at gstelement.c line 2443
  • #20 gst_element_set_state
    at gstelement.c line 2344
  • #21 gst_bin_element_set_state
    at gstbin.c line 2221
  • #22 gst_bin_change_state_func
    at gstbin.c line 2526
  • #23 gst_pipeline_change_state
    at gstpipeline.c line 478
  • #24 gst_play_bin_change_state
    at gstplaybin2.c line 3988
  • #25 gst_element_change_state
    at gstelement.c line 2487
  • #26 gst_element_continue_state
    at gstelement.c line 2198
  • #27 gst_element_change_state
    at gstelement.c line 2524
  • #28 gst_element_set_state_func
    at gstelement.c line 2443
  • #29 gst_element_set_state
    at gstelement.c line 2344
  • #30 CLS_GSTPlayer::InnerStop
    at player/CLS_Gst_Player.cpp line 772
  • #31 CLS_GSTPlayer::Stop
    at player/CLS_Gst_Player.cpp line 1004
  • #32 CLS_AVL_GST_Player_API::Stop
    at api_interface/avl_avc_gst_player_api.cpp line 58
  • #33 AutoPlayingThread
    at autotest.cxx line 330
  • #34 start_thread
  • #35 clone
  • #0 pthread_cond_wait
  • #1 g_cond_wait
    from /home/zhangyp/rootfs_for_hunter/usr/lib/libglib-2.0.so.0
  • #2 gst_queue_loop
    at gstqueue.c line 1132
  • #3 gst_task_func
    at gsttask.c line 316
  • #4 default_func
    at gsttaskpool.c line 70
  • #5 g_thread_pool_thread_proxy
    from /home/zhangyp/rootfs_for_hunter/usr/lib/libglib-2.0.so.0
  • #6 g_thread_proxy
    from /home/zhangyp/rootfs_for_hunter/usr/lib/libglib-2.0.so.0
  • #7 start_thread
  • #8 clone
  • #9 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.
Comment 1 zhangyanping 2012-10-19 06:34:48 UTC
Can anybody give me some  help ? Dear Tim-Philipp Müller and Wim Taymans, come out please.
Comment 2 André Klapper 2012-10-19 20:34:53 UTC
zhangyanping: Please be patient. Obviously developers don't provide user support within 3 hours at any time of the day in any timezone.

Please provide a minimal testcase here so we don't have to guess steps, and please provide information about your EXACT gstreamer version.
Comment 3 zhangyanping 2012-10-22 05:33:38 UTC
Thank you André. Because this case happens at a small probability event. So even I provide the test case, it would be little help. I provide the callstack of the case,  and could you take an eye on it. I will continue to test it myself and I just want to get some advice form you.
Comment 4 Tim-Philipp Müller 2012-10-22 19:07:42 UTC
What is the exact version of GStreamer core and gst-plugins-base that you are using?

Even small probability events can eventually be reproduced, you just need to repeat them often enough in a loop :-)
Comment 5 Tim-Philipp Müller 2012-11-16 09:18:08 UTC
zhangyanping: ping?
Comment 6 zhangyanping 2012-11-28 07:09:14 UTC
Thank you Tim. I am sorry to reply to you so late. I have checked the problems. I run gstreamer as a media player in my embeded device. And it will play thousands of media in a playlist. The memory for user space is only 64MB. So if I run it for hours,  there will be memory fragmentation and memory leak, and gstreamer can not create thread. At this time, if I want to stop the pipeline, it will in deadlock because the thread do not exist.

And the gstreamer verison I am using now is 0.11.3.  I am not sure if this version has the problem of memory leaks. But according to my tests, it exists. So I am planning to swtich to the latest version of gstreamer.

Thanks again.
Comment 7 Tim-Philipp Müller 2012-11-28 14:57:19 UTC
Thanks for getting back to us.

64MB, I bet that brings out some interesting issues :)

You should definitely upgrade to a 1.x version of GStreamer (to which 0.11.x was the precursor), I don't think this issue will be fixed there.

However, it still sounds like something that should be fixed somewhere. Next time it dead locks, perhaps you could get a strack trace from all threads?
Comment 8 zhangyanping 2012-12-03 06:35:03 UTC
(In reply to comment #7)
> Thanks for getting back to us.
> 
> 64MB, I bet that brings out some interesting issues :)
> 
> You should definitely upgrade to a 1.x version of GStreamer (to which 0.11.x
> was the precursor), I don't think this issue will be fixed there.
> 
> However, it still sounds like something that should be fixed somewhere. Next
> time it dead locks, perhaps you could get a strack trace from all threads?

OK, Tim, I will remember this thing.