[gstreamer-bugs] [Bug 167593] New: new opt locking deadlock

[bugzilla-daemon at bugzilla.gnome.org]

Please DO NOT reply to this by email. All additional comments should be made in
the comments box of this bug report.

 http://bugzilla.gnome.org/show_bug.cgi?id=167593
 GStreamer | gstreamer (core) | Ver: HEAD CVS

           Summary: new opt locking deadlock
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: rbultje at ronald.bitfreak.net
         QAContact: gstreamer-bugs at lists.sourceforge.net
                CC: all-bugs at bugzilla.gnome.org


Here's a testcase that may result in a deadlock (happens when playing live
ogg/theora streams using totem):

create a mainbin which outputs data (fakesrc ! queue), have an output thread ({
fakesink }), run the mainbin, add the thread to the bin, set to playing and only
then link queue to fakesink (all in mainbin context). Inside
gstoptimalscheduler.c:2128, it will hang on the lock. The thread iterates, tries
to get data but since it's not linked yet, it will fail to do so:

LOG   (0xa347730 - 307931:51:17.236616000)       scheduler(20745)
gstoptimalscheduler.c(1271):gst_opt_scheduler_schedule_run_queue:<GstOptScheduler at 0xa33a798>
scheduling group 0xa346690
INFO  (0xa347730 - 307931:51:17.236736000)       scheduler(20745)
gstoptimalscheduler.c(1183):schedule_group: not scheduling group 0xa346690
without entry
LOG   (0xa347730 - 307931:51:17.236839000)       scheduler(20745)
gstoptimalscheduler.c(1284):gst_opt_scheduler_schedule_run_queue:<GstOptScheduler at 0xa33a798>
done scheduling group 0xa346690

During this, apparently the lock is held in some way, because the other thread
will hang after this log message (easily traceable by searching for the
thread-ID in the logfile):

INFO  (0xa2dce10 - 307931:51:17.234590000)       scheduler(20745)
gstoptimalscheduler.c(2123):gst_opt_scheduler_pad_link: scheduling link between
preroll_audio_src0:src and aconv:sink

Here's a partial backtrace:

#0  0x004107a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x00668eee in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0
#2  0x00665df4 in _L_mutex_lock_29 () from /lib/tls/libpthread.so.0
#3  0x01d1ebb0 in ?? ()
#4  0x034e54c8 in ?? ()
#5  0x07c4e180 in ?? () from /usr/lib/libglib-2.0.so.0
#6  0x08d9379c in ?? ()
#7  0x07c4e500 in g_thread_use_default_impl () from /usr/lib/libglib-2.0.so.0
#8  0x034e54e8 in ?? ()
#9  0x07c0f0d8 in g_static_rec_mutex_lock () from /usr/lib/libglib-2.0.so.0
Previous frame identical to this frame (corrupt stack?)

Currently still working on valgrinding, since that last line doesn't look too
good, but it does seem to hang in the static mutex in opt. Once valgrind is
complete, I'll try to prepare a testcase to reproduce in lab settings.

------- You are receiving this mail because: -------
You are the assignee for the bug.
You are the QA contact for the bug.