<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 18 Jun 2022 at 03:33, Eyal Lebedinsky <<a href="mailto:eyal@eyal.emu.id.au">eyal@eyal.emu.id.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This issue is now tracked on bugzilla as<br>
        <a href="https://bugzilla.rpmfusion.org/show_bug.cgi?id=6327" rel="noreferrer" target="_blank">https://bugzilla.rpmfusion.org/show_bug.cgi?id=6327</a><br>
<br>
On 30/05/2022 11.00, Eyal Lebedinsky wrote:<br>
> Running f34 up-to-date.<br>
> <br>
> Recently, following an update of mythtv and the kernel, mythbackend started crahing even when not recording or watching.<br>
> Does anyone else see this?<br>
<br><br></blockquote><div>Interesting, this is not the same error but definitely related. The previous bug was about parsing the header and extending one byte beyond the header into the payload and this looks like it is accessing one byte beyond the payload. If you do not get the previous error anymore this means that the fix did work. Which I was not 100% sure about because I could not reproduce the issue.</div><div>As with the previous bug, this now shows up because (1) somebody changed the C-style arrays to C++-style std::arrays and (2) it looks like that in your rpmfusion build there is array boundary checking enabled on std::array accesses and (3) the streams that you encounter are composed so that this does happen.</div><div>It is not usual to do array boundary checking on this code level because of performance reasons; this code is executed for every 188 byte packet that is received and I leave the math for you how many packets per second this can be for 40 Mbit/s satellite transport stream.</div><div>I will have a look at it.</div><div><br></div><div>Klaas.</div><div><br></div><div><br></div><div><br></div><div><br></div></div></div>