After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 724209 - gst-rtsp-server: session deadlock while unpreparing
gst-rtsp-server: session deadlock while unpreparing
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gst-rtsp-server
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-02-12 07:19 UTC by Aleix Conchillo Flaqué
Modified: 2014-02-15 01:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Aleix Conchillo Flaqué 2014-02-12 07:19:56 UTC
I am running a series of stress tests on the gst-rtsp-server. Today, I've hit the deadlock you can see at the end.

Thread 39 and Thread 18 are waiting on the same mutex, which is from the session.

It seems unprepare is also waiting on something (Thread 38). As unprepare is waiting, it is blocking the session lock (by calling gst_rtsp_session_filter) and that's causing the other two threads to lock.

Unfortunately, I only have symbols for gst-rtsp-server. I'll look into it tomorrow unless someone is faster.

-----

Thread 18 (Thread 0x7ff326b43700 (LWP 9084))

  • #0 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 132
  • #1 _L_lock_1006
    from /lib/x86_64-linux-gnu/libpthread.so.0
  • #2 __pthread_mutex_lock
    at pthread_mutex_lock.c line 101
  • #3 g_mutex_lock
    from /opt/oblong/deps-64-9/lib/libglib-2.0.so.0
  • #4 gst_rtsp_session_touch
    at rtsp-session.c line 506
  • #5 g_closure_invoke
    from /opt/oblong/deps-64-9/lib/libgobject-2.0.so.0
  • #6 ??
    from /opt/oblong/deps-64-9/lib/libgobject-2.0.so.0
  • #7 g_signal_emit_valist
    from /opt/oblong/deps-64-9/lib/libgobject-2.0.so.0
  • #8 g_signal_emit
    from /opt/oblong/deps-64-9/lib/libgobject-2.0.so.0
  • #9 ??
    from /opt/oblong/deps-64-9/lib/gstreamer-1.0/libgstrtpmanager.so
  • #10 ??
    from /opt/oblong/deps-64-9/lib/gstreamer-1.0/libgstrtpmanager.so
  • #11 ??
    from /opt/oblong/deps-64-9/lib/gstreamer-1.0/libgstrtpmanager.so
  • #12 ??
    from /opt/oblong/deps-64-9/lib/libgstreamer-1.0.so.0
  • #13 ??
    from /opt/oblong/deps-64-9/lib/libgstreamer-1.0.so.0
  • #14 gst_proxy_pad_chain_default
    from /opt/oblong/deps-64-9/lib/libgstreamer-1.0.so.0
  • #15 ??
    from /opt/oblong/deps-64-9/lib/libgstreamer-1.0.so.0
  • #16 ??
    from /opt/oblong/deps-64-9/lib/libgstreamer-1.0.so.0
  • #17 ??
    from /opt/oblong/deps-64-9/lib/gstreamer-1.0/libgstcoreelements.so
  • #18 ??
    from /opt/oblong/deps-64-9/lib/libgstreamer-1.0.so.0
  • #19 ??
    from /opt/oblong/deps-64-9/lib/libgstreamer-1.0.so.0
  • #20 ??
    from /opt/oblong/deps-64-9/lib/libgstbase-1.0.so.0
  • #21 ??
    from /opt/oblong/deps-64-9/lib/libgstreamer-1.0.so.0
  • #22 ??
    from /opt/oblong/deps-64-9/lib/libglib-2.0.so.0
  • #23 ??
    from /opt/oblong/deps-64-9/lib/libglib-2.0.so.0
  • #24 start_thread
    at pthread_create.c line 308
  • #25 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 112
  • #26 ??

Comment 1 Aleix Conchillo Flaqué 2014-02-15 01:47:56 UTC
Not so sure it's gst-rtsp-server fault. So, resolving as invalid until I perform more tests, have debugging symbols, etc.