From b374eb765880ac868e4bf0e424627db31b5dc26d Mon Sep 17 00:00:00 2001 From: Paul Davis Date: Fri, 20 Sep 2019 12:18:49 -0600 Subject: fix crash when doing rapid (ongoing-locate-interrupting) locates --- libs/ardour/transport_fsm.cc | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) (limited to 'libs') diff --git a/libs/ardour/transport_fsm.cc b/libs/ardour/transport_fsm.cc index 02faafef9b..7399209d6e 100644 --- a/libs/ardour/transport_fsm.cc +++ b/libs/ardour/transport_fsm.cc @@ -348,7 +348,24 @@ void TransportFSM::interrupt_locate (Event const & l) const { assert (l.type == Locate); - DEBUG_TRACE (DEBUG::TFSMEvents, "tfsm::interrupt\n"); + DEBUG_TRACE (DEBUG::TFSMEvents, string_compose ("tfsm::interrupt to %1 versus %2\n", l.target, _last_locate.target)); + + /* Because of snapping (e.g. of mouse position) we could be + * interrupting an existing locate to the same position. If we go ahead + * with this, the code in Session::do_locate() will notice that it's a + * repeat position, will do nothing, will queue a "locate_done" event + * that will arrive in the next process cycle. But this event may be + * processed before the original (real) locate has completed in the + * butler thread, and processing it may transition us back to Rolling + * before some (or even all) tracks are actually ready. + * + * So, we must avoid this from happening, and this seems like the + * simplest way. + */ + + if (l.target == _last_locate.target && !l.force) { + return; + } /* maintain original "with-roll" choice of initial locate, even though * we are interrupting the locate to start a new one. */ -- cgit v1.2.3