GNOME Bugzilla – Bug 704002
inpuselector - deadlock on next track (sometimes), racy
Last modified: 2013-07-12 08:10:39 UTC
Thread 6: gst_input_selector_release_pad -> input selector lock then post_activate -> pad stream lock Thread 7 : gst_pad_chain_data_unchecked -> pad stream lock then gst_selector_pad_chain -> input stream lock
+ Trace 232224
Thread 6 (Thread 0x7fc108bf8700 (LWP 6689))
sorry this is on next track (second one , might affect other next ones , have not tested) using playbin.
commit 717ad2091209bf3b736cfd9784ca1e710a5020a6 Author: Sebastian Dröge <slomo@circular-chaos.org> Date: Fri Jul 12 10:08:26 2013 +0200 inputselector: Deactivate and remove pad without the inputselector lock Otherwise we might get deadlocks caused by lock order inversion: During the chain function the stream lock is first locked and then the inputselector lock. During pad release we first locked the inputselector lock and then deactivating the pad would lock the stream lock. There's no reason why the inputselector lock should be required while deactivating and removing the pad, it's only needed before. https://bugzilla.gnome.org/show_bug.cgi?id=704002