lili93's session (#ardour) triggered this w/jackd 512fpp:
Drag/Drop copy a latent plugin from one track to another while rolling.
The GUI-thread as well as the auto-connect thread concurrently call
jack_recompute_total_latencies(). The auto-connect thread holds
a process lock while doing so. The GUI does not use any mutexes.
This randomly deadlocks in libjack.
backtrace: https://pastebin.com/6m3KGhWS
ChanCount output_offset;
};
+ Glib::Threads::Mutex _update_latency_lock;
+
typedef std::queue<AutoConnectRequest> AutoConnectQueue;
Glib::Threads::Mutex _auto_connect_queue_lock;
AutoConnectQueue _auto_connect_queue;
if (_state_of_the_state & (InitialConnecting|Deletion)) {
return;
}
+ /* this lock is not usually contended, but under certain conditions,
+ * update_latency_compensation may be called concurrently.
+ * e.g. drag/drop copy a latent plugin while rolling.
+ * GUI thread (via route_processors_changed) and
+ * auto_connect_thread_run may race.
+ */
+ Glib::Threads::Mutex::Lock lx (_update_latency_lock, Glib::Threads::TRY_LOCK);
+ if (!lx.locked()) {
+ /* no need to do this twice */
+ return;
+ }
bool some_track_latency_changed = update_route_latency (false, false);