Deadlock on Debian 12

During the using of gmediarender, occasionally encountered a problem with the 49494 port being unavailable. It appears that gmediarender is waiting for a lock when operating with GStreamer. It works normally after restarting gmediarender.

how can I find the root cause of this locking issue between gmediarender and GStreamer?

this is the gmediarender thread, blocked while waiting lock


Thread 11 (Thread 0x7f84c75366c0 (LWP 147972) "gmediarender"):
#0 0x00007f84fa73efbb in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f84fa74532a in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007f84faab525a in ?? () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#3 0x00007f84faab58fe in gst_pad_set_active () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#4 0x00007f84faa8e121 in ?? () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#5 0x00007f84faaa4c74 in gst_iterator_fold () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#6 0x00007f84faa8e7a6 in ?? () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#7 0x00007f84faa90ae6 in ?? () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#8 0x00007f84faa90d19 in ?? () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#9 0x00007f84fa0e49de in ?? () from /lib/x86_64-linux-gnu/gstreamer-1.0/libgstcoreelements.so
#10 0x00007f84faa92f30 in gst_element_change_state () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#11 0x00007f84faa9359b in ?? () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#12 0x00007f84faa701eb in ?? () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#13 0x00007f84faabd696 in ?? () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#14 0x00007f84fa471281 in ?? () from /lib/x86_64-linux-gnu/gstreamer-1.0/libgstplayback.so
#15 0x00007f84faa92f30 in gst_element_change_state () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#16 0x00007f84faa9359b in ?? () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#17 0x000055e106d1b2a5 in output_gstreamer_stop () at output_gstreamer.c:165
#18 0x000055e106d173d9 in stop (event=0x7f84c7535a40) at upnp_transport.c:746
#19 0x000055e106d195fa in handle_action_request (ar_event=0x7f8454005d80, priv=0x55e1081b8730) at upnp_device.c:343
#20 event_handler (EventType=<optimized out>, event=0x7f8454005d80, userdata=0x55e1081b8730) at upnp_device.c:398
#21 0x00007f84fa99d830 in ?? () from /snap/wave/30/usr/lib/x86_64-linux-gnu/libupnp.so.13
#22 0x00007f84fa99ea5a in ?? () from /snap/wave/30/usr/lib/x86_64-linux-gnu/libupnp.so.13
#23 0x00007f84fa996137 in ?? () from /snap/wave/30/usr/lib/x86_64-linux-gnu/libupnp.so.13
#24 0x00007f84fa742044 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#25 0x00007f84fa7c261c in ?? () from /lib/x86_64-linux-gnu/libc.so.6

this thread owns the lock that gmediarender waits

Thread 20 (Thread 0x7f84aa7fc6c0 (LWP 153419) "multiqueue984:s"):
#0 0x00007f84fa7ba559 in syscall () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f84faae0fd4 in ?? () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#2 0x00007f84faae1e37 in ?? () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#3 0x00007f84faa8285d in gst_clock_id_wait () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#4 0x00007f84fa0e6414 in ?? () from /lib/x86_64-linux-gnu/gstreamer-1.0/libgstcoreelements.so
#5 0x00007f84faaaf2a9 in ?? () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#6 0x00007f84faab17b1 in gst_pad_push_data () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#7 0x00007f84faab8b6b in gst_pad_push () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#8 0x00007f84faa9b333 in gst_proxy_pad_chain_default () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#9 0x00007f84faaaf2a9 in ?? () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#10 0x00007f84faab17b1 in ?? () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#11 0x00007f84faab8b6b in gst_pad_push () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#12 0x00007f84faa9b333 in gst_proxy_pad_chain_default () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#13 0x00007f84faaaf2a9 in ?? () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#14 0x00007f84faab17b1 in ?? () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#15 0x00007f84faab8b6b in gst_pad_push () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#16 0x00007f84fa0eeebb in ?? () from /lib/x86_64-linux-gnu/gstreamer-1.0/libgstcoreelements.so
#17 0x00007f84faae8441 in ?? () from /lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
#18 0x00007f84fabf56ca in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x00007f84fabf4cfd in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x00007f84fa742044 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#21 0x00007f84fa7c261c in ?? () from /lib/x86_64-linux-gnu/libc.so.6

This deadlocks on the streaming thread of the (probably) queue, which is shut down when setting the pipeline’s state to READY or NULL.

Without more details about the pipeline or the code involved, there’s not much more that can be said here. This can for example happen if only shutting down elements downstream of that queue but not the queue itself, but it can also be a buggy element.

You might also want to install or download debug symbols for gstreamer or glib, to get a better stack trace, fwiw.