[gstreamer-bugs] [Bug 361769] New: Deadlock in gstpad.c

Thu Oct 12 11:12:25 PDT 2006

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=361769

  GStreamer | gstreamer (core) | Ver: 0.10.6

           Summary: Deadlock in gstpad.c
           Product: GStreamer
           Version: 0.10.6
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: ivanohe at abacom.com
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified

Hi,

I found an hard to reproduce deadlock in gstreamer that occur when the pad are
linking.

I also found a patch for it. The problem occur in gstreamer-0.10.6 and also in
gstreamer-0.10.10

I'll start with a description of the problem:

first, we need to create an audio avi:
gst-launch-0.10 audiotestsrc num-buffers=10 ! avimux ! filesink
location=testaudio.avi

and do this :
gst-launch-0.10 -f -v DUMMYsink name=sink location=out.raw filesrc
location=testaudio.avi ! avidemux .audio_00 ! queue ! sink.audio_00

DUMMYsink is a sink filter (using collect data) that does nothing usefull (this
is a test). The code is in attachment in folder dummysink. Also, I put in
attachment a modified gstbin.c and gstpad.c that do sleep at some critical
point to make the deadlock occurs faster (file from gstreamer-0.10.6). Those
files are in folder sleep_bug/

When it deadlock, here's the stack trace :

(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7cf92ee in __lll_mutex_lock_wait () from
/lib/tls/i686/cmov/libpthread.so.0
#2  0xb7cf5ffb in _L_mutex_lock_33 () from /lib/tls/i686/cmov/libpthread.so.0
#3  0xbfb7c468 in ?? ()
#4  0xb7d83288 in ?? () from /opt/trx/glib/2.8.6/lib/libglib-2.0.so.0
#5  0xbfb7c468 in ?? ()
#6  0xb7cf9da0 in __nanosleep_nocancel () from
/lib/tls/i686/cmov/libpthread.so.0
#7  0xb7e520a0 in ?? () from
/opt/trx/gstreamer/gstreamer/0.10.6/lib/libgstreamer-0.10.so.0
#8  0x080966b8 in ?? ()
#9  0x080966e8 in ?? ()
#10 0xbfb7c468 in ?? ()
#11 0xb7e05dc0 in gst_pad_get_peer (pad=0x606f) at gstpad.c:2365
#12 0xb7e05dc0 in gst_pad_get_peer (pad=0x80966e8) at gstpad.c:2365
#13 0xb7de43f6 in update_degree (element=0x8096a90, bit=0x809b4d0) at
gstbin.c:1547
#14 0xb7d24d6d in IA__g_list_foreach (list=0xfffffffc, func=0xb7de4330
<update_degree>, user_data=0x809b4d0) at glist.c:670
#15 0xb7de4862 in gst_bin_sort_iterator_resync (bit=0x809b4d0) at gstbin.c:1660
#16 0xb7de49ca in gst_bin_sort_iterator_new (bin=0x8113bd0) at gstbin.c:1700
#17 0xb7de4d22 in gst_bin_iterate_sorted (bin=0x8113bd0) at gstbin.c:1731
#18 0xb7de4e17 in gst_bin_change_state_func (element=0x8113bd0,
transition=GST_STATE_CHANGE_PAUSED_TO_PLAYING) at gstbin.c:1805
#19 0xb7e0c877 in gst_pipeline_change_state (element=0x8113bd0,
transition=GST_STATE_CHANGE_PAUSED_TO_PLAYING) at gstpipeline.c:492
#20 0xb7df3da7 in gst_element_change_state (element=0x8113bd0,
transition=3083857908) at gstelement.c:2177
#21 0xb7df433d in gst_element_set_state_func (element=0x8113bd0,
state=GST_STATE_PLAYING) at gstelement.c:2139
#22 0xb7df308a in gst_element_set_state (element=0x8113bd0,
state=GST_STATE_PLAYING) at gstelement.c:2049
#23 0x0804b416 in ?? ()
#24 0x08113bd0 in ?? ()
#25 0x00000004 in ?? ()
#26 0xbfb7c9f8 in ?? ()
#27 0x0804b18c in ?? ()
#28 0xb7d8fd78 in ?? ()
#29 0xb7bcab0c in ?? () from /lib/tls/i686/cmov/libc.so.6
#30 0xb7f7eff4 in ?? () from /lib/ld-linux.so.2
#31 0xb7d8fad0 in ?? ()
#32 0xb7cf0c10 in ?? () from /lib/tls/i686/cmov/libpthread.so.0
#33 0xbfb7c6fc in ?? ()
#34 0xb7f743e4 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#35 0xb7bd5ec2 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#36 0x08049eb1 in ?? ()

(gdb) t 3
[Switching to thread 3 (Thread -1231848528 (LWP 24689))]#0  0xffffe410 in
__kernel_vsyscall ()
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7cf92ee in __lll_mutex_lock_wait () from
/lib/tls/i686/cmov/libpthread.so.0
#2  0xb7cf5ffb in _L_mutex_lock_33 () from /lib/tls/i686/cmov/libpthread.so.0
#3  0xb6936b08 in ?? ()
#4  0xe0ddfe59 in ?? ()
#5  0x00000001 in ?? ()
#6  0x08055a80 in ?? ()
#7  0x00000001 in ?? ()
#8  0xb7e520a0 in ?? () from
/opt/trx/gstreamer/gstreamer/0.10.6/lib/libgstreamer-0.10.so.0
#9  0x08113bd0 in ?? ()
#10 0x08096a90 in ?? ()
#11 0xb6936b38 in ?? ()
#12 0xb7de06b0 in gst_object_get_parent (object=0x6071) at gstobject.c:835
#13 0xb7de06b0 in gst_object_get_parent (object=0x8096a90) at gstobject.c:835
#14 0xb7e05557 in gst_pad_link (srcpad=0x809bf30, sinkpad=0x80966e8) at
gstpad.c:1605
#15 0xb7e22661 in pad_link_maybe_ghosting (src=0x809bf30, sink=0x80966e8) at
gstutils.c:1270
#16 0xb7e22df6 in gst_element_link_pads (src=0x81144c8, srcpadname=0x80974c8
"audio_00", dest=0x8096a90, destpadname=0x0) at gstutils.c:1414
#17 0xb7e238a2 in gst_element_link_pads_filtered (src=0x81144c8,
srcpadname=0x80974c8 "audio_00", dest=0x8096a90, destpadname=0x0, filter=0x0)
    at gstutils.c:1606
#18 0xb7e35da7 in gst_parse_found_pad (src=0x81144c8, pad=0x809bf30,
data=0x8113690) at grammar.y:410
#19 0xb7daf03c in IA__g_cclosure_marshal_VOID__OBJECT (closure=0x8060898,
return_value=0x0, n_param_values=2, param_values=0x81144c8,
    invocation_hint=0xb6936e28, marshal_data=0x0) at gmarshal.c:636
#20 0xb7d9897c in IA__g_closure_invoke (closure=0x8060898, return_value=0x0,
n_param_values=2, param_values=0xb6936f40, invocation_hint=0xb6936e28)
    at gclosure.c:492
#21 0xb7dacf8c in signal_emit_unlocked_R (node=0x805b718, detail=0,
instance=0x81144c8, emission_return=0x0, instance_and_params=0xb6936f40)
    at gsignal.c:2485
#22 0xb7dadedd in IA__g_signal_emit_valist (instance=0x81144c8, signal_id=1,
detail=0, var_args=0xb69370d0 "\uffff\uffff\017\b0\uffff\t\b") at
gsignal.c:2244
#23 0xb7dae15b in IA__g_signal_emit (instance=0x81144c8, signal_id=7, detail=0)
at gsignal.c:2288
#24 0xb7df0e2a in gst_element_add_pad (element=0x81144c8, pad=0x809bf30) at
gstelement.c:636
#25 0xb77cd7ec in gst_avi_demux_parse_stream (element=0x81144c8, buf=0x80fc8e8)
at gstavidemux.c:1185
#26 0xb77d00e2 in gst_avi_demux_stream_header (avi=0x81144c8) at
gstavidemux.c:2128
#27 0xb77d2c74 in gst_avi_demux_loop (pad=0xfffffffc) at gstavidemux.c:2641
#28 0xb7e1cf1e in gst_task_func (task=0x809b100, tclass=0x80fc698) at
gsttask.c:193
#29 0xb7d44be7 in g_thread_pool_thread_proxy (data=0x80e84e0) at
gthreadpool.c:114
#30 0xb7d42c41 in g_thread_create_proxy (data=0x809b1d0) at gthread.c:564
#31 0xb7cf4381 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#32 0xb7c89bfe in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb)

I was able to find where it occur in the code :
In gstpad.c, inside function gst_pad_link_check_hierarchy when it call
"gst_object_get_parent"
In gstbin.c, inside function update_degree,line 1544 when it call
"gst_pad_get_peer"

what occurs is this 

Filter1-----Filter2

Thread 3 in gst_pad_link_prepare lock Filter 1 source pad and Filter 2 sink
pad. later in gst_pad_link_check_hierarchy, it tries to get the grandparents of
each pad using the gst_object_get_parent function. This function lock the
element to do it's job.

Thread 1 lock Filter 2 element and try to do a pad_get_peer on it's sink pad.
This function tries to lock the source pad of Filter 1.

The solution is not to use gst_object_get_parent inside the function
gst_pad_link_check_hierarchy but GST_OBJECT_PARENT instead. The pointers are
only used to evaluate if the condition fail so it seems safe to do so.

For example, using the files in folder sleep_fix/ work without deadlock.

I will post the attachment and patch next.

-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email