Slave backend connecting can cause the master to lock in QMutexLocker

[Mark Buechler <Mark.Buechler@…>]

When a slave backend connects, it's possible for the backend to lock up in Scheduler::GetNextLiveTVDir() and Scheduler::SlaveConnected?() each waiting for the other to release the QMutex lock on reclist_locker. Backtrace attached.

I'm not sure the best way to fix this, but I'm testing out the following in ::SlaveConnected?():

{

int lock_tries = 0; bool is_locked = false;

while (!is_locked && (lock_tries < 5)) {

lock_tries++; is_locked = reclist_lock->tryLock(); if (!is_locked)

usleep(100);

}

if (!is_locked)

return;

...

reclist_locker->unlock();

}

[Shane Shrybman]

Hi Mark,

Does the attached patch also work for you? It does the tryLock() in GetNextLiveTVDir() instead.

It has a little extra code/debugging in it for now, the final version would just immediately return from GetNextLiveTVDir() after one tryLock() attempt. This is a rare event and we already have to provide a fallback for GetNextLiveTVDir(), namely sgroup.FindNextDirMostFree?(), so that simple fix should be ok.

[laga]

Mark,

have you had time to test gnome42's patch?

[stuartm]

No response to request for information after 3 months.