13
0

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.
This commit is contained in:
Robin Gareus 2016-12-12 03:13:16 +01:00
parent b52bf1a42c
commit d3803c54de

View File

@ -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;
}