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: Mark Buechler <Mark.Buechler@…> Owned by: Isaac Richards
Priority: minor Milestone: 0.22
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no


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)



if (!is_locked)





Attachments (1)

GetNextLiveTVDir_tryLock.diff (1019 bytes) - added by Shane Shrybman 12 years ago.

Download all attachments as: .zip

Change History (4)

comment:1 Changed 12 years ago by Shane Shrybman

Milestone: unknown0.22
Status: newinfoneeded_new
Type: defectpatch
Version: 0.21head

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.

Changed 12 years ago by Shane Shrybman

comment:2 Changed 11 years ago by laga


have you had time to test gnome42's patch?

comment:3 Changed 11 years ago by stuartm

Resolution: invalid
Status: infoneeded_newclosed

No response to request for information after 3 months.

Note: See TracTickets for help on using tickets.