<div dir="ltr">On Sun, Feb 26, 2017 at 2:52 PM Piotr Oniszczuk <<a href="mailto:piotr.oniszczuk@gmail.com">piotr.oniszczuk@gmail.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">John,<br class="gmail_msg">
<br class="gmail_msg">
With this commit I see highly decreased BE availability.<br class="gmail_msg">
During 2 days of normal usage I had 3 deadlocks where BE stopped answering to FE requests.<br class="gmail_msg">
All 3 cases were during LiveTV channel change.<br class="gmail_msg">
gdb trace from deadlocked BE: <a href="http://pastebin.com/sGAUhEwe" rel="noreferrer" class="gmail_msg" target="_blank">http://pastebin.com/sGAUhEwe</a><br class="gmail_msg">
BE log around failed channel change: <a href="http://pastebin.com/msaBBb0K" rel="noreferrer" class="gmail_msg" target="_blank">http://pastebin.com/msaBBb0K</a><br class="gmail_msg">
When BE is deadlocked, fe log says: <a href="http://pastebin.com/fXP8EMv1" rel="noreferrer" class="gmail_msg" target="_blank">http://pastebin.com/fXP8EMv1</a><br class="gmail_msg">
<br class="gmail_msg">
All 3 deadlocks were on channel where tuning takes over 10sec (CAS subsystem).<br class="gmail_msg">
I have hypothesis that <a href="https://github.com/MythTV/mythtv/commit/34ad18e0c951a289e5bbebea065b17359c1bfc1d" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/MythTV/mythtv/commit/34ad18e0c951a289e5bbebea065b17359c1bfc1d</a> causes<br class="gmail_msg">
issue when tuning takes longer that 10sec during LiveTV channel change.<br class="gmail_msg">
<br class="gmail_msg">
May You look on this when You will have sec of free time?<br class="gmail_msg">
<br class="gmail_msg">
br<br class="gmail_msg"></blockquote><div><br></div><div>If you change the timer check from 10000 to 60000, does that 'fix' it for you?<br><br>    if (ringBufferCheckTimer.isRunning() &&<br>        ringBufferCheckTimer.elapsed() > 60000)<br>    {<br>        LOG(VB_RECORD, LOG_WARNING, LOC + "It is has been over 60 seconds "<br>            "since we've checked for a ringbuffer switch.");<br>        CheckForRingBufferSwitch();<br>    }<br></div><div><br>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.<br></div><div><br>John<br></div></div></div>