Opened 16 years ago
Closed 16 years ago
Last modified 16 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)
by , 16 years ago
Attachment: | gcore.log.1264390476.gz added |
---|
comment:1 by , 16 years ago
Component: | MythTV - General → MythTV - DVB |
---|---|
Owner: | changed from | to
comment:2 by , 16 years ago
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 by , 16 years ago
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 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
backtrace