Fix a potential deadlock/crash (here tape-track peak-file)

read_peaks_with_fpp() already holds _lock, build_peaks_from_scratch()
takes the _lock again.

Depending on glib[mm] and the threading lib it may either result in a
deadlock, or with EDEADLK in undefined behavior when a
non-recursive lock is released twice.

diff --git a/libs/ardour/audiosource.cc b/libs/ardour/audiosource.cc
index 123bc229180d9d70fa8e2fc7e4a95b54d3df76bd..12c12099d5a352d090ca398d42931be1afd83c9f 100644 (file)
--- a/libs/ardour/audiosource.cc
+++ b/libs/ardour/audiosource.cc
@@ -387,7 +387,9 @@ AudioSource::read_peaks_with_fpp (PeakData *peaks, framecnt_t npeaks, framepos_t
 
                if (statbuf.st_size < expected_file_size) {
                        warning << string_compose (_("peak file %1 is truncated from %2 to %3"), _peakpath, expected_file_size, statbuf.st_size) << endmsg;
+                       lm.release(); // build_peaks_from_scratch() takes _lock
                        const_cast<AudioSource*>(this)->build_peaks_from_scratch ();
+                       lm.acquire ();
                        if (g_stat (_peakpath.c_str(), &statbuf) != 0) {
                                error << string_compose (_("Cannot open peakfile @ %1 for size check (%2) after rebuild"), _peakpath, strerror (errno)) << endmsg;
                        }