[gstreamer-bugs] [Bug 561789] [volume] deadlocks with a controller attached

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=561789

  GStreamer | gst-plugins-base | Ver: HEAD CVS




------- Comment #2 from Jonathan Matthew  2008-11-21 11:04 UTC -------
And here's a stack trace:

(gdb) i th
  2 Thread 0xb73bdb90 (LWP 19256)  0xb7fdb424 in __kernel_vsyscall ()
  1 Thread 0xb7e1b8c0 (LWP 19254)  0xb7fdb424 in __kernel_vsyscall ()
(gdb) t 2
[Switching to thread 2 (Thread 0xb73bdb90 (LWP 19256))]#0  0xb7fdb424 in
__kernel_vsyscall ()
(gdb) bt
#0  0xb7fdb424 in __kernel_vsyscall ()
#1  0xb7fb2c99 in __lll_lock_wait () from /lib/i686/cmov/libpthread.so.0
#2  0xb7fae0c4 in _L_lock_89 () from /lib/i686/cmov/libpthread.so.0
#3  0xb7fad9f2 in pthread_mutex_lock () from /lib/i686/cmov/libpthread.so.0
#4  0xb7fc1e1a in volume_set_property (object=0x8e9e098, prop_id=3,
value=0xb73bcf68, pspec=0x8d8c9d8) at gstvolume.c:770
#5  0xb7723d77 in IA__g_object_set_property (object=0x8e9e098,
property_name=0x8e62d28 "volume", value=0xb73bcfe8)
    at /tmp/buildd/glib2.0-2.16.6/gobject/gobject.c:697
#6  0xb785475a in gst_controller_sync_values (self=0x8d2f770, timestamp=0) at
gstcontroller.c:698
#7  0xb7861601 in gst_object_sync_values (object=0x8e9e098, timestamp=0) at
gsthelper.c:187
#8  0xb7fc17eb in volume_transform_ip (base=0x8e9e098, outbuf=0x8ece6a0) at
gstvolume.c:715
#9  0xb783c7c5 in gst_base_transform_handle_buffer (trans=0x8e9e098,
inbuf=0x8ece6a0, outbuf=0xb73bd1a8)
    at gstbasetransform.c:1816
#10 0xb783e09e in gst_base_transform_chain (pad=0x8e978e0, buffer=0x8ece6a0) at
gstbasetransform.c:1921
#11 0xb77b86b5 in gst_pad_chain_unchecked (pad=0x8e978e0, buffer=0x8ece6a0) at
gstpad.c:3890
#12 0xb77b9aaa in gst_pad_push (pad=0x8e97820, buffer=0x8ece6a0) at
gstpad.c:4057
#13 0xb78362b1 in gst_base_src_loop (pad=0x8e97820) at gstbasesrc.c:2275
#14 0xb77d98a3 in gst_task_func (task=0x8ece018, tclass=0x8d82e40) at
gsttask.c:192
#15 0xb76b87e6 in g_thread_pool_thread_proxy (data=0x8d82ed0) at
/tmp/buildd/glib2.0-2.16.6/glib/gthreadpool.c:265
#16 0xb76b714f in g_thread_create_proxy (data=0x8ec7de8) at
/tmp/buildd/glib2.0-2.16.6/glib/gthread.c:635
#17 0xb7fac4c0 in start_thread () from /lib/i686/cmov/libpthread.so.0
#18 0xb7efc61e in clone () from /lib/i686/cmov/libc.so.6

What appears to be happening is that the base transform lock is acquired in
frame 10 (before calling gst_base_transform_handle_buffer) and frame 4 is
trying to acquire it again.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=561789.