Opened 8 years ago
Closed 17 months ago
#12636 closed Bug Report - Hang/Deadlock (Trac EOL)
BE deadlock if LiveTV zap to program wihch just ends
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | major | Milestone: | 29.2 |
| Component: | MythTV - General | Version: | Master Head |
| Severity: | medium | Keywords: | LiveTV |
| Cc: | Ticket locked: | no |
Description
I consider this bug as serious as it makes BE deadlocked with only restart as solution.
Issue: when user is changing LiveTV to channel on which current program just ends, it is easy to deadlock BE.
Severity of this issue is higher than You may think. Many users are starting zapping around full quarters/halves/full hours (xx:00, xx:30, xx:15[45]) as broadcasters usually are emitting commercials end of current program - so user zaps to another channel just to not watch commercials which begins. If zap to new channel is zap channel where current program also ends - BE will deadlock. Very unpleasant. I have reports of this issue from many users using LiveTV frequently.
Steeps to reproduce:
-start LiveTV
-identify another channel where program will just end, let say at xx:yy
-wait till few sec. before xx:yy and jump to this another channel
-it is highly probable that after jump BE will deadlock
Easy way to reproduce is: start LiveTV; browse EPG OSD in LiveTV to find channel with end time nearest to current time; wait till this time; Just few sec.before this time jump to this channel; BE will deadlock
I'm attaching BE logs and BE gdb traces from 2 such deadlocks. 1st was during normal zapping; second was reproduced for getting gdb trace for this ticket
Attachments (4)
Change History (13)
Changed 8 years ago by
| Attachment: | deadlock.trace.txt added |
|---|
comment:1 Changed 8 years ago by
| Milestone: | unknown → 0.28 |
|---|---|
| Priority: | minor → major |
comment:2 Changed 8 years ago by
Hmm. Reverting 916e43bb5 fixes issue for me. It looks like BE deadlocks are present in normal BE usage. No special conditions like described in original ticket are needed to trigger deadlock. Reverting 916e43bb5 gives me stable BE again (3 weeks of stable operation; 20 attempts to provoke deadlock and no issue).
Changed 8 years ago by
| Attachment: | filetransfer.patch added |
|---|
comment:3 Changed 8 years ago by
I suspect that it's the FileTransfer? object that blocks everything. Rather than reverting 916e43bb5, can you try the attached patch that unlocks sockListLock while the FileTransfer? objects are being created?
comment:6 Changed 6 years ago by
| Milestone: | 29.0 → 29.1 |
|---|
comment:7 Changed 6 years ago by
| Milestone: | 29.1 → 0.28.2 |
|---|
Moving remaining open tickets to 0.28.2 milestone
comment:8 Changed 6 years ago by
| Milestone: | 0.28.2 → 29.2 |
|---|
Moving remaining open tickets to 29.2 milestone
First deadlock trace