[mythtv] 34ad18e0c951a289e5bbebea065b17359c1bfc1d causes deadlock on BE when tuning takes longer than 10sec

[John P Poet]

On Sun, Feb 26, 2017 at 2:52 PM Piotr Oniszczuk <piotr.oniszczuk at gmail.com>
wrote:

> John,
>
> With this commit I see highly decreased BE availability.
> During 2 days of normal usage I had 3 deadlocks where BE stopped answering
> to FE requests.
> All 3 cases were during LiveTV channel change.
> gdb trace from deadlocked BE: http://pastebin.com/sGAUhEwe
> BE log around failed channel change: http://pastebin.com/msaBBb0K
> When BE is deadlocked, fe log says: http://pastebin.com/fXP8EMv1
>
> All 3 deadlocks were on channel where tuning takes over 10sec (CAS
> subsystem).
> I have hypothesis that
> https://github.com/MythTV/mythtv/commit/34ad18e0c951a289e5bbebea065b17359c1bfc1d
> causes
> issue when tuning takes longer that 10sec during LiveTV channel change.
>
> May You look on this when You will have sec of free time?
>
> br
>

If you change the timer check from 10000 to 60000, does that 'fix' it for
you?

    if (ringBufferCheckTimer.isRunning() &&
        ringBufferCheckTimer.elapsed() > 60000)
    {
        LOG(VB_RECORD, LOG_WARNING, LOC + "It is has been over 60 seconds "
            "since we've checked for a ringbuffer switch.");
        CheckForRingBufferSwitch();
    }

If so, that would prove your hypothesis.  However, I only see one place
where nextRingBuffer is not protected by a mutex and that is in the
destructor, so I am not seeing where this would cause a deadlock.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20170226/ed483ea7/attachment.html>