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 727102 - rtsp-media: deadlock with dynamic pipelines when preroll fails
rtsp-media: deadlock with dynamic pipelines when preroll fails
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-rtsp-server
git master
Other Linux
: Normal normal
: 1.3.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-03-26 17:12 UTC by Aleix Conchillo Flaqué
Modified: 2014-04-08 12:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
don't add stream if media is not preparing (2.75 KB, patch)
2014-03-26 17:34 UTC, Aleix Conchillo Flaqué
none Details | Review

Description Aleix Conchillo Flaqué 2014-03-26 17:12:00 UTC
I've ht a deadlock when having a dynamic pipeline and the preroll fails because of a timeout waiting for the preroll to happen.

The problem is that a timeout happens while waiting for prerolling to happen. Then, th emedia is unprepared. However, the dynamic pipeline is still working and finally adds a pad, therefore calling rtsp-media:pad_added_cb while the media is unpreparing.

Thread 2 shows the dynamic pipeline, Thread 6 show how the media is being prepared and then unprepared. Also, in Thread 4 the bus source is also waiting for state_lock to unblock.

-----

Thread 2 (Thread 0x7fbcaffff700 (LWP 7806))

  • #0 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 132
  • #1 _L_lock_903
    from /lib/x86_64-linux-gnu/libpthread.so.0
  • #2 __pthread_mutex_lock
    at pthread_mutex_lock.c line 82
  • #3 pad_added_cb
    at rtsp-media.c line 1933
  • #4 g_cclosure_marshal_VOID__OBJECTv
    at gmarshal.c line 1312
  • #5 _g_closure_invoke_va
    at gclosure.c line 840
  • #6 g_signal_emit_valist
    at gsignal.c line 3238
  • #7 g_signal_emit
    at gsignal.c line 3386
  • #8 gst_element_add_pad
    at gstelement.c line 694
  • #9 rtsp_viddle_factory_payload_add_encoder
    at rtsp-viddle-factory-payload.C line 406
  • #10 g_cclosure_marshal_VOID__OBJECTv
    at gmarshal.c line 1312
  • #11 _g_closure_invoke_va
    at gclosure.c line 840
  • #12 g_signal_emit_valist
    at gsignal.c line 3238
  • #13 g_signal_emit
    at gsignal.c line 3386
  • #14 gst_element_add_pad
    at gstelement.c line 694
  • #15 gst_decode_bin_expose
    at gstdecodebin2.c line 4019
  • #16 source_pad_blocked_cb
    at gstdecodebin2.c line 4197
  • #17 probe_hook_marshal
    at gstpad.c line 3110
  • #18 g_hook_list_marshal
    at ghook.c line 676
  • #19 do_probe_callbacks
    at gstpad.c line 3204
  • #20 gst_pad_push_event_unchecked
    at gstpad.c line 4715
  • #21 push_sticky
    at gstpad.c line 3381
  • #22 events_foreach
    at gstpad.c line 533
  • #23 check_sticky
    at gstpad.c line 3437
  • #24 gst_pad_push_event
    at gstpad.c line 4865
  • #25 gst_type_find_element_sink_event
    at gsttypefindelement.c line 678
  • #26 gst_pad_send_event_unchecked
    at gstpad.c line 5052
  • #27 gst_pad_push_event_unchecked
    at gstpad.c line 4748
  • #28 push_sticky
    at gstpad.c line 3381
  • #29 events_foreach
    at gstpad.c line 533
  • #30 check_sticky
    at gstpad.c line 3437
  • #31 gst_pad_push_event
    at gstpad.c line 4865
  • #32 event_forward_func
    at gstpad.c line 2778
  • #33 gst_pad_forward
    at gstpad.c line 2732
  • #34 gst_pad_event_default
    at gstpad.c line 2829
  • #35 gst_pad_send_event_unchecked
    at gstpad.c line 5052
  • #36 gst_pad_push_event_unchecked
    at gstpad.c line 4748
  • #37 push_sticky
    at gstpad.c line 3381
  • #38 events_foreach
    at gstpad.c line 533
  • #39 check_sticky
    at gstpad.c line 3437
  • #40 gst_pad_push_event
    at gstpad.c line 4865
  • #41 gst_single_queue_push_one
    at gstmultiqueue.c line 1112
  • #42 gst_multi_queue_loop
    at gstmultiqueue.c line 1338
  • #43 gst_task_func
    at gsttask.c line 319
  • #44 g_thread_pool_thread_proxy
    at gthreadpool.c line 309
  • #45 g_thread_proxy
    at gthread.c line 798
  • #46 start_thread
    at pthread_create.c line 308
  • #47 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 112
  • #48 ??

Comment 1 Aleix Conchillo Flaqué 2014-03-26 17:16:26 UTC
The old backtrace had some changes so it would be hard for you to get to the right lines.

The following backtrace has been obtained with commit

  dffdbbf0906201ec6d6711d1e80e6245182d517c

-----

Thread 2 (Thread 0x7fdc927fc700 (LWP 12007))

  • #0 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 132
  • #1 _L_lock_903
    from /lib/x86_64-linux-gnu/libpthread.so.0
  • #2 __pthread_mutex_lock
    at pthread_mutex_lock.c line 82
  • #3 pad_added_cb
    at rtsp-media.c line 1927
  • #4 g_cclosure_marshal_VOID__OBJECTv
    at gmarshal.c line 1312
  • #5 _g_closure_invoke_va
    at gclosure.c line 840
  • #6 g_signal_emit_valist
    at gsignal.c line 3238
  • #7 g_signal_emit
    at gsignal.c line 3386
  • #8 gst_element_add_pad
    at gstelement.c line 694
  • #9 rtsp_viddle_factory_payload_add_encoder
    at rtsp-viddle-factory-payload.C line 406
  • #10 g_cclosure_marshal_VOID__OBJECTv
    at gmarshal.c line 1312
  • #11 _g_closure_invoke_va
    at gclosure.c line 840
  • #12 g_signal_emit_valist
    at gsignal.c line 3238
  • #13 g_signal_emit
    at gsignal.c line 3386
  • #14 gst_element_add_pad
    at gstelement.c line 694
  • #15 gst_decode_bin_expose
    at gstdecodebin2.c line 4019
  • #16 source_pad_blocked_cb
    at gstdecodebin2.c line 4197
  • #17 probe_hook_marshal
    at gstpad.c line 3110
  • #18 g_hook_list_marshal
    at ghook.c line 676
  • #19 do_probe_callbacks
    at gstpad.c line 3204
  • #20 gst_pad_push_event_unchecked
    at gstpad.c line 4715
  • #21 push_sticky
    at gstpad.c line 3381
  • #22 events_foreach
    at gstpad.c line 533
  • #23 check_sticky
    at gstpad.c line 3437
  • #24 gst_pad_push_event
    at gstpad.c line 4865
  • #25 gst_type_find_element_sink_event
    at gsttypefindelement.c line 678
  • #26 gst_pad_send_event_unchecked
    at gstpad.c line 5052
  • #27 gst_pad_push_event_unchecked
    at gstpad.c line 4748
  • #28 push_sticky
    at gstpad.c line 3381
  • #29 events_foreach
    at gstpad.c line 533
  • #30 check_sticky
    at gstpad.c line 3437
  • #31 gst_pad_push_event
    at gstpad.c line 4865
  • #32 event_forward_func
    at gstpad.c line 2778
  • #33 gst_pad_forward
    at gstpad.c line 2732
  • #34 gst_pad_event_default
    at gstpad.c line 2829
  • #35 gst_pad_send_event_unchecked
    at gstpad.c line 5052
  • #36 gst_pad_push_event_unchecked
    at gstpad.c line 4748
  • #37 push_sticky
    at gstpad.c line 3381
  • #38 events_foreach
    at gstpad.c line 533
  • #39 check_sticky
    at gstpad.c line 3437
  • #40 gst_pad_push_event
    at gstpad.c line 4865
  • #41 gst_single_queue_push_one
    at gstmultiqueue.c line 1112
  • #42 gst_multi_queue_loop
    at gstmultiqueue.c line 1338
  • #43 gst_task_func
    at gsttask.c line 319
  • #44 g_thread_pool_thread_proxy
    at gthreadpool.c line 309
  • #45 g_thread_proxy
    at gthread.c line 798
  • #46 start_thread
    at pthread_create.c line 308
  • #47 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 112
  • #48 ??

Comment 2 Aleix Conchillo Flaqué 2014-03-26 17:34:38 UTC
Created attachment 273010 [details] [review]
don't add stream if media is not preparing

The following patch solves the deadlock, but I'm not really convinced is the right way to do this.

Probably a better way to do this would be making the preroll asynchronous as suggested by the FIXME note in the code. I think it would fix it too.
Comment 3 Wim Taymans 2014-04-08 12:53:58 UTC
Please check if this fixes it as well:

commit fd5e949169d71fe23102d6120853e28ef45f5ae4
Author: Wim Taymans <wtaymans@redhat.com>
Date:   Tue Apr 8 14:49:41 2014 +0200

    media: release the state lock when going to NULL
    
    Set our state to UNPREPARING and release the state-lock before
    setting the pipeline to the NULL state. This way, any pad-added
    callback will be able to take the state-lock and check that we are now
    unpreparing instead of deadlocking.
    
    Fixes https://bugzilla.gnome.org/show_bug.cgi?id=727102