[mythtv-commits] Ticket #9704: backend deadlocks up with Protocol version check failure.

[MythTV]

#9704: backend deadlocks up with Protocol version check failure.
-----------------------------------+----------------------------
 Reporter:  brian@…                |          Owner:
     Type:  Bug Report - General   |         Status:  new
 Priority:  critical               |      Milestone:  unknown
Component:  MythTV - General       |        Version:  0.24-fixes
 Severity:  high                   |     Resolution:
 Keywords:                         |  Ticket locked:  0
-----------------------------------+----------------------------

Comment (by markk):

 This is not an area of the code I'm familiar with, but here's my not so
 quick but still quite dirty analysis of the backtrace (using latest
 0.24-fixes code):-

 Thread 1 (the main thread)

 - has received a MASTER_UPDATE_PROG_INFO message (mainserver.cpp @ 1001).
 I presume this is the result of a recording finishing, though I'm not too
 sure. In the process of handling that message, it asks for the recording
 status of the program referenced in the message. It gets this from the
 scheduler - scheduler.cpp, GetRecStatus @ 1534 and immediately tries to
 obtain a lock on access to the scheduler which it presumably never
 obtains. The main loop is now deadlocked.


 Thread 20 - the scheduler thread

 - is in the middle of the Scheduler::RunScheduler loop (scheduler.cpp @
 1688). This obtains the scheduler lock at line 1730 and is still holding
 it when it calls AutoExpire::Update at line 2152. AutoExpire::Update tries
 to get a lock on the global AutoExpire object - and again presumably
 fails.

 Thread 18 - the AutoExpire thread

 - is in the middle of AutoExpire::RunExpirer (line 310) and is holding the
 global autoexpire lock. RunExpirer then proceeds down to the ProgramInfo
 class where it is accessing the database. It's not clear whether the
 database access is stalled for some reason or whether this is just where
 the interrupt happened to land.

 So the main thread (1) is waiting on the scheduler lock, the scheduler
 thread (20) holds that lock but is waiting for the autoexpire lock, the
 autoexpire thread (18) holds the autoexpire lock - but I have no idea if
 it's released or not.

-- 
Ticket URL: <http://code.mythtv.org/trac/ticket/9704#comment:5>
MythTV <http://code.mythtv.org/trac>
MythTV Media Center