Opened 3 years ago

Last modified 11 months ago

#12636 new Bug Report - Hang/Deadlock

BE deadlock if LiveTV zap to program wihch just ends

Reported by: warpme@… 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)

deadlock.trace.txt (123.0 KB) - added by warpme@… 3 years ago.
First deadlock trace
be.log (13.5 KB) - added by warpme@… 3 years ago.
First deadlock BE log
deadlock1.trace.txt (103.6 KB) - added by warpme@… 3 years ago.
Second deadlock trace
filetransfer.patch (1.1 KB) - added by Jonatan Lindblad 3 years ago.

Download all attachments as: .zip

Change History (12)

Changed 3 years ago by warpme@…

Attachment: deadlock.trace.txt added

First deadlock trace

Changed 3 years ago by warpme@…

Attachment: be.log added

First deadlock BE log

Changed 3 years ago by warpme@…

Attachment: deadlock1.trace.txt added

Second deadlock trace

comment:1 Changed 3 years ago by Stuart Auchterlonie

Milestone: unknown0.28
Priority: minormajor

comment:2 Changed 3 years ago by warpme@…

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 3 years ago by Jonatan Lindblad

Attachment: filetransfer.patch added

comment:3 Changed 3 years ago by Jonatan Lindblad

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:4 Changed 3 years ago by Stuart Auchterlonie

Milestone: 0.280.29

Moving to 0.29

comment:5 Changed 3 years ago by Stuart Auchterlonie

Milestone: 0.2929.0

Milestone renamed

comment:6 Changed 13 months ago by Stuart Auchterlonie

Milestone: 29.029.1

comment:7 Changed 11 months ago by Stuart Auchterlonie

Milestone: 29.10.28.2

Moving remaining open tickets to 0.28.2 milestone

comment:8 Changed 11 months ago by Stuart Auchterlonie

Milestone: 0.28.229.2

Moving remaining open tickets to 29.2 milestone

Note: See TracTickets for help on using tickets.