Opened 13 years ago
Closed 11 years ago
#5341 closed patch (invalid)
Slave backend connecting can cause the master to lock in QMutexLocker
Reported by: | Owned by: | Isaac Richards | |
---|---|---|---|
Priority: | minor | Milestone: | 0.22 |
Component: | mythtv | Version: | head |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
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();
}
Attachments (1)
Change History (4)
comment:1 Changed 12 years ago by
Milestone: | unknown → 0.22 |
---|---|
Status: | new → infoneeded_new |
Type: | defect → patch |
Version: | 0.21 → head |
Changed 12 years ago by
Attachment: | GetNextLiveTVDir_tryLock.diff added |
---|
comment:3 Changed 11 years ago by
Resolution: | → invalid |
---|---|
Status: | infoneeded_new → closed |
No response to request for information after 3 months.
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.