GNOME Bugzilla – Bug 769764
multiqueue: Deadlock in _sink_activate_mode when releasing pad
Last modified: 2018-11-03 12:35:33 UTC
I am using GStreamer 1.8.2 to create a pipeline that has multiple input branches, created dynamically after D-Bus method call. Each of the branch contains shmsrc do_timestamp=true is_live=true ! capsfilter. They are wrapped into bin, where capsfilter's src pad becomes ghost pad. Each of such branches is linked with multiqueue, and multiqueue is linked to the audiomixer. It may happen that such branches are added/removed in the runtime. In case of adding I just create them, request new pads on the multiqueue, audiomixer and link them (no pausing or pad blocking involved). In case of removing I just unlink the bin, release pads (no pausing or pad blocking involved). In case of errors (e.g. when SHM socket is closed) I override bin's virtual handle_message and intercept ERROR messages (I don't want them to propagate accross whole pipeline), and remove bin using method above in the next idle cycle of the mainloop. This is what I got today, after D-Bus call that involved adding a branch. (gdb) thr a a bt
+ Trace 236521
Thread 10 (Thread 0x7f36b491c700 (LWP 16701))
Thread 9 (Thread 0x7f36a2ffd700 (LWP 16292))
Thread 8 (Thread 0x7f36a37fe700 (LWP 16129))
Thread 7 (Thread 0x7f36b5530700 (LWP 21373))
Thread 6 (Thread 0x7f36b5d31700 (LWP 21372))
Thread 5 (Thread 0x7f36b6532700 (LWP 21371))
Thread 1 (Thread 0x7f36c216e700 (LWP 21367))
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/181.