[gstreamer-bugs] [Bug 577671] New: [rtspsrc] deadlock on shutdown (locking order problem?)

GStreamer (bugzilla.gnome.org) bugzilla-daemon at bugzilla.gnome.org
Wed Apr 1 17:39:58 PDT 2009


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=577671

  GStreamer | gst-plugins-good | Ver: git
           Summary: [rtspsrc] deadlock on shutdown (locking order problem?)
           Product: GStreamer
           Version: git
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: t.i.m at zen.co.uk
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


Running the test program from bug #577318 I quickly get deadlocks like this:

(gdb) thread apply all bt

Thread 8 (Thread 0xb48deb90 (LWP 22492)):
#0  0xb80d3422 in __kernel_vsyscall ()
#1  0xb7d67075 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/tls/i686/cmov/libpthread.so.0
#2  0xb806c09b in gst_system_clock_async_thread (clock=0x9f2c000) at
gstsystemclock.c:385
#3  0xb7dda02f in g_thread_create_proxy (data=0x9f209d0) at
/build/buildd/glib2.0-2.18.2/glib/gthread.c:635
#4  0xb7d6350f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#5  0xb7ce0a0e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 6 (Thread 0xb58e0b90 (LWP 22490)):
#0  0xb80d3422 in __kernel_vsyscall ()
#1  0xb7d69d09 in __lll_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb7d65114 in _L_lock_89 () from /lib/tls/i686/cmov/libpthread.so.0
#3  0xb7d64a42 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0
#4  0xb7dd9f73 in IA__g_static_rec_mutex_lock (mutex=0x9e7d7f8) at
/build/buildd/glib2.0-2.18.2/glib/gthread.c:313
#5  0xb7a92fba in gst_rtspsrc_loop (src=0x9f0e240) at gstrtspsrc.c:2773
#6  0xb80719e3 in gst_task_func (task=0x9f571e0, tclass=0x9e142c0) at
gsttask.c:192
#7  0xb7ddb6c6 in g_thread_pool_thread_proxy (data=0x9e14350) at
/build/buildd/glib2.0-2.18.2/glib/gthreadpool.c:265
#8  0xb7dda02f in g_thread_create_proxy (data=0x9f49170) at
/build/buildd/glib2.0-2.18.2/glib/gthread.c:635
#9  0xb7d6350f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#10 0xb7ce0a0e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 1 (Thread 0xb7bbd8c0 (LWP 22482)):
#0  0xb80d3422 in __kernel_vsyscall ()
#1  0xb7d69d09 in __lll_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb7d65114 in _L_lock_89 () from /lib/tls/i686/cmov/libpthread.so.0
#3  0xb7d64a42 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0
#4  0xb7dd9f73 in IA__g_static_rec_mutex_lock (mutex=0x9f14bb0) at
/build/buildd/glib2.0-2.18.2/glib/gthread.c:313
#5  0xb7a8e362 in gst_rtspsrc_close (src=0x9f0e240) at gstrtspsrc.c:4655
#6  0xb7a910e0 in gst_rtspsrc_change_state (element=0x9f0e240,
transition=GST_STATE_CHANGE_PAUSED_TO_READY) at gstrtspsrc.c:5192
#7  0xb8033f78 in gst_element_change_state (element=0x9f0e240,
transition=GST_STATE_CHANGE_PAUSED_TO_READY) at gstelement.c:2430
#8  0xb8036ebc in gst_element_set_state_func (element=0x9f0e240,
state=GST_STATE_READY) at gstelement.c:2380
#9  0xb80331b2 in gst_element_set_state (element=0x9f0e240,
state=GST_STATE_READY) at gstelement.c:2283
#10 0xb8024e8f in gst_bin_change_state_func (element=0x9f075a0,
transition=GST_STATE_CHANGE_PAUSED_TO_READY) at gstbin.c:2062
#11 0xb80574ba in gst_pipeline_change_state (element=0x9f075a0,
transition=GST_STATE_CHANGE_PAUSED_TO_READY) at gstpipeline.c:465
#12 0xb8033f78 in gst_element_change_state (element=0x9f075a0,
transition=GST_STATE_CHANGE_PAUSED_TO_READY) at gstelement.c:2430
#13 0xb8033d0e in gst_element_continue_state (element=0x9f075a0,
ret=GST_STATE_CHANGE_NO_PREROLL) at gstelement.c:2134
#14 0xb80342ab in gst_element_change_state (element=0x9f075a0,
transition=GST_STATE_CHANGE_PLAYING_TO_PAUSED) at gstelement.c:2474
#15 0xb8036ebc in gst_element_set_state_func (element=0x9f075a0,
state=GST_STATE_NULL) at gstelement.c:2380
#16 0xb80331b2 in gst_element_set_state (element=0x9f075a0,
state=GST_STATE_NULL) at gstelement.c:2283
#17 0x08048bdb in main ()

which looks like a locking order problem to me:

 - streaming thread takes STREAMING_LOCK in _loop()

 - application thread in gst_rtspsrc_close():
     - takes STATE_LOCK
     - does gst_task_stop()
     - takes STREAM_LOCK, waits for streaming thread to release it

 - streaming thread takes STATE_LOCK in _loop_interleaved(),
   waits for application thread to release it

Not 100% sure what the correct solution is at this point, so just filing a bug
for now.


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




More information about the Gstreamer-bugs mailing list