[Bug 693224] New: appsrc deadlocks when setting pad caps before pushing buffer

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=693224
  GStreamer | gst-plugins-base | 1.0.5

           Summary: appsrc deadlocks when setting pad caps before pushing
                    buffer
    Classification: Platform
           Product: GStreamer
           Version: 1.0.5
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: rodolfo at rodsoft.org
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


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:

#0  __lll_lock_wait () at
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:132
#1  0x00007ffff662b15b in _L_lock_1032 () from /lib64/libpthread.so.0
#2  0x00007ffff662b0dc in __pthread_mutex_lock (mutex=0x7fffb4075fc0) at
pthread_mutex_lock.c:101
#3  0x00007ffff4f74171 in g_mutex_lock (mutex=mutex at entry=0x7fffb4003a18) at
gthread-posix.c:210
#4  0x00007ffff5a9b754 in gst_object_get_parent (object=0x7fffb4003a00) at
gstobject.c:730
#5  0x00007ffff5a9b896 in gst_object_dispatch_properties_changed
(object=0x7fffa4006510, n_pspecs=1, pspecs=0x7fffadffa7a8) at gstobject.c:463
#6  0x00007ffff5838ca3 in g_object_notify_by_spec_internal (pspec=<optimized
out>, object=0x7fffa4006510) at gobject.c:1136
#7  g_object_notify_by_pspec (object=object at entry=0x7fffa4006510,
pspec=<optimized out>) at gobject.c:1237
#8  0x00007ffff5acd929 in gst_pad_store_sticky_event
(pad=pad at entry=0x7fffa4006510, event=event at entry=0x7fffb8001d20) at
gstpad.c:4429
#9  0x00007ffff5ad7ff0 in gst_pad_push_event (pad=0x7fffa4006510,
event=0x7fffb8001d20) at gstpad.c:4626
#10 0x00007ffff5d94222 in gst_pad_set_caps (caps=<optimized out>,
pad=<optimized out>) at ../../../gst/gstcompat.h:71
#11 gst_base_src_set_caps (src=src at entry=0x7ffff5d640f0 <_gst_debug_min>,
caps=caps at entry=0x7fffadffaa68) at gstbasesrc.c:881
#12 0x00007ffff5fbc253 in gst_app_src_do_negotiate (basesrc=0x7ffff5d640f0
<_gst_debug_min>) at gstappsrc.c:937
#13 0x00007ffff5fbc533 in gst_app_src_create (bsrc=0x7fffb4003a00,
offset=18446744073709551615, size=4096, buf=0x7fffadffaa68) at gstappsrc.c:1016
#14 0x00007ffff5d90bf2 in gst_base_src_get_range (src=src at entry=0x7fffb4003a00,
offset=offset at entry=18446744073709551615, length=length at entry=4096,
buf=buf at entry=0x7fffadffab78) at
 gstbasesrc.c:2355
#15 0x00007ffff5d9219b in gst_base_src_loop (pad=0x7fffa4006510) at
gstbasesrc.c:2600
#16 0x00007ffff5afe6a1 in gst_task_func (task=0x1165ea0) at gsttask.c:316
#17 0x00007ffff4f5b3b2 in g_thread_pool_thread_proxy (data=<optimized out>) at
gthreadpool.c:309
#18 0x00007ffff4f5ab95 in g_thread_proxy (data=0x7fffb8002c50) at gthread.c:797
#19 0x00007ffff6628ec6 in start_thread (arg=0x7fffadffb700) at
pthread_create.c:305
#20 0x00007ffff0be18ad in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:115


In another thread that calls gst_app_src_set_caps, this function first lock
appsrc's mutex, than locks priv->mutex. The backtrace for this thread is:

#0  __lll_lock_wait () at
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:132
#1  0x00007ffff662b15b in _L_lock_1032 () from /lib64/libpthread.so.0
#2  0x00007ffff662b0dc in __pthread_mutex_lock (mutex=0x7fffb40013b0) at
pthread_mutex_lock.c:101
#3  0x00007ffff4f74171 in g_mutex_lock (mutex=mutex at entry=0x7fffb4003d80) at
gthread-posix.c:210
#4  0x00007ffff5fbd5ae in gst_app_src_set_caps (appsrc=0x7fffb4003a00,
caps=0x7fffa400bf20) at gstappsrc.c:1119
#5  0x0000000000c1cd8e in rod::media::source::push (this=0x7fffad396ac0,
frame=...) at /home/rodolfo/src/ds/dsclient/lib/rmedia/rmedia/source.cpp:173
#6  0x0000000000a732e1 in ds::client::StreamModule::do_run (this=0x110bca0) at
/home/rodolfo/src/ds/dsclient/dsclient/stream.cpp:313
#7  0x0000000000a88c55 in ds::client::Thread::run (this=0x110bca0) at
/home/rodolfo/src/ds/dsclient/dsclient/thread.cpp:138
#8  0x0000000000a88257 in operator() (__closure=0x7fffdc1132b0) at
/home/rodolfo/src/ds/dsclient/dsclient/thread.cpp:37
#9  0x0000000000a89970 in
boost::detail::thread_data<ds::client::Thread::start()::<lambda()> >::run(void)
(this=0x7fffdc113110) at /usr/include/boost/thread/detail/thread.hpp:78
#10 0x00007ffff4ab651b in boost::(anonymous namespace)::thread_proxy
(param=<optimized out>) at libs/thread/src/pthread/thread.cpp:153
#11 0x00007ffff6628ec6 in start_thread (arg=0x7fffad397700) at
pthread_create.c:305
#12 0x00007ffff0be18ad in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:115


So in the end one thread keeps waiting for the other, and vice-versa.

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