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 693224 - appsrc deadlocks when setting pad caps before pushing buffer
appsrc deadlocks when setting pad caps before pushing buffer
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
1.0.5
Other Linux
: Normal major
: 1.0.6
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-02-05 18:59 UTC by Rodolfo Schulz de Lima
Modified: 2013-02-06 09:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Rodolfo Schulz de Lima 2013-02-05 18:59:17 UTC 
There's a deadlock that sometimes happens caused by gst_app_src_create leaving priv->mutex locked while executing gst_app_src_caps_negotiate, which in turn end up calling functions that ultimately lock the appsrc object. This processing happens in "appsrc:src" thread. The backtrace for this thread is:

+ Trace 231490

  • #0 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 132
  • #1 _L_lock_1032
    from /lib64/libpthread.so.0
  • #2 __pthread_mutex_lock
    at pthread_mutex_lock.c line 101
  • #3 g_mutex_lock
    at gthread-posix.c line 210
  • #4 gst_object_get_parent
    at gstobject.c line 730
  • #5 gst_object_dispatch_properties_changed
    at gstobject.c line 463
  • #6 g_object_notify_by_spec_internal
    at gobject.c line 1136
  • #7 g_object_notify_by_pspec
    at gobject.c line 1237
  • #8 gst_pad_store_sticky_event
    at gstpad.c line 4429
  • #9 gst_pad_push_event
    at gstpad.c line 4626
  • #10 gst_pad_set_caps
    at ../../../gst/gstcompat.h line 71
  • #11 gst_base_src_set_caps
    at gstbasesrc.c line 881
  • #12 gst_app_src_do_negotiate
    at gstappsrc.c line 937
  • #13 gst_app_src_create
    at gstappsrc.c line 1016
  • #14 gst_base_src_get_range
    at gstbasesrc.c line 2355
  • #15 gst_base_src_loop
    at gstbasesrc.c line 2600
  • #16 gst_task_func
    at gsttask.c line 316
  • #17 g_thread_pool_thread_proxy
    at gthreadpool.c line 309
  • #18 g_thread_proxy
    at gthread.c line 797
  • #19 start_thread
    at pthread_create.c line 305
  • #20 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 115
  • #0 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 132
  • #1 _L_lock_1032
    from /lib64/libpthread.so.0
  • #2 __pthread_mutex_lock
    at pthread_mutex_lock.c line 101
  • #3 g_mutex_lock
    at gthread-posix.c line 210
  • #4 gst_app_src_set_caps
    at gstappsrc.c line 1119
  • #5 rod::media::source::push
    at /home/rodolfo/src/ds/dsclient/lib/rmedia/rmedia/source.cpp line 173
  • #6 ds::client::StreamModule::do_run
    at /home/rodolfo/src/ds/dsclient/dsclient/stream.cpp line 313
  • #7 ds::client::Thread::run
    at /home/rodolfo/src/ds/dsclient/dsclient/thread.cpp line 138
  • #8 operator()
    at /home/rodolfo/src/ds/dsclient/dsclient/thread.cpp line 37
  • #9 boost::detail::thread_data<ds::client::Thread::start()::<lambda()> >::run(void)
    at /usr/include/boost/thread/detail/thread.hpp line 78
  • #10 boost::(anonymous namespace)::thread_proxy
    at libs/thread/src/pthread/thread.cpp line 153
  • #11 start_thread
    at pthread_create.c line 305
  • #12 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 115 


So in the end one thread keeps waiting for the other, and vice-versa.
Comment 1 Rodolfo Schulz de Lima 2013-02-05 19:02:59 UTC 
bugzilla reformatted my description, leaving out some information I wrote.

There's two backtraces there... the first is the one I'm referring to in my first paragraph.

The second one is for the thread that calls gst_app_src_set_caps. This function locks appsrc mutex *then* locks priv->mutex. Since this is the reverse order of locking of these mutexes in the other thread, one thread end up waiting for the other, and vice versa, leading to a deadlock.
Comment 2 Rodolfo Schulz de Lima 2013-02-05 19:17:09 UTC 
Here's another place where priv->mutex is being locked *before* appsrc's mutex, leading to a deadlock because another thread is locking these mutexes in the reverse other:

+ Trace 231491

  • #0 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 132
  • #1 _L_lock_1032
    from /lib64/libpthread.so.0
  • #2 __pthread_mutex_lock
  • #3 g_mutex_lock
    at gthread-posix.c line 2
  • #4 gst_app_src_internal_get_caps
    at g stappsrc.c line 559
  • #5 gst_base_src_default_query
    at gstbasesrc.c line 1211
  • #6 gst_app_src_query
    at gst appsrc.c line 826
  • #7 gst_pad_query
    at gstpad.c line 3418
  • #8 gst_pad_query_caps
    at gstutils.c line 2751
  • #9 gst_base_src_default_negotiate
    at gstbasesr c.c line 3006
  • #10 gst_app_src_negotiate
    at gstappsrc.c line 954
  • #11 gst_base_src_negotiate
    at gstbasesrc.c line 3080
  • #12 gst_base_src_loop
    at gstbasesrc.c line 2569
  • #13 gst_task_func
    at gsttask.c line 316
  • #14 g_thread_pool_thread_proxy
    at gthreadpool.c line 3
  • #15 g_thread_proxy
    at gthread.c line 797
  • #16 start_thread
    at pthread_create.c line 305
  • #17 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 115 

priv->mutex is being locked here:
gstappsrc.c:953 (gst_app_src_negotiate)

then appsrc's mutex is being locked here:
gstappsrc.c:559 (gst_app_src_internal_get_caps)
Comment 3 Wim Taymans 2013-02-06 09:15:03 UTC 
commit a673fc7977df382f449fd097dffffba0b53bce92
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Wed Feb 6 10:00:27 2013 +0100

    appsrc: always take mutex before object lock
    
    The locking order is to first take the appsrc mutex and then the
    object lock.
    
    Fixes https://bugzilla.gnome.org/show_bug.cgi?id=693224