Opened 14 years ago
Closed 14 years ago
Last modified 14 years ago
#7988 closed defect (fixed)
Deadlock in DVBChannel
Reported by: | Mark Spieth | Owned by: | Janne Grunau |
---|---|---|---|
Priority: | minor | Milestone: | 0.23 |
Component: | MythTV - DVB | Version: | head |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
there is a suspected deadlock in dvbchannel.
backtrace attached using gcore proposed solution patch attached.
Attachments (2)
Change History (7)
Changed 14 years ago by
Attachment: | gcore.log.1264390476.gz added |
---|
comment:1 Changed 14 years ago by
Component: | MythTV - General → MythTV - DVB |
---|---|
Owner: | changed from Isaac Richards to Janne Grunau |
comment:2 Changed 14 years ago by
symptom is that the backend stops responding.
search for "this=0xa7ba90|mtx = 0xa7bb5[89]"
4 threads want this lock. the one that has it is the TVRec::RunTV TVRec::StartRecording? thread which should be ok Expirer thread and HttpStatus? request handling thread.
it appears as though the RunTV thread is wating for hwlock but cant get it which means one of the other threads may be holding it.
I suspect DVBChannel hwlock should be inited as QMutex::Recursive that should fix this. will test but it doesn't happen often so feedback will take a while.
comment:3 Changed 14 years ago by
Milestone: | unknown → 0.23 |
---|---|
Status: | new → accepted |
Version: | unknown → head |
Yes, a recursive look would fix it. The locking in DVBChannel is incorrect. Open() calls Close() when InitializeInputs?() fails and both try hold hw_lock.
I'll commit the patch. The recursive Mutex is imho less ugly than the code duplication.
comment:4 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
backtrace