<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 4 Jun 2022 at 16:00, Gary Buhrmaster <<a href="mailto:gary.buhrmaster@gmail.com">gary.buhrmaster@gmail.com</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">On Sat, Jun 4, 2022 at 9:04 AM Eyal Lebedinsky <<a href="mailto:eyal@eyal.emu.id.au" target="_blank">eyal@eyal.emu.id.au</a>> wrote:<br>
<br>
> Here on f32 mythtv version is<br>
>          mythtv-backend-32.0-1.30.20220510git26079f815a.fc34.x86_64<br>
> $ mythbackend --version<br>
> MythTV Branch : fixes/31<br>
<br>
This sounds like a packager versioning<br>
issue, as your previous email had you<br>
upgrading to a fixes/32 version.  You<br>
may want to contact your packager.<br>
<br>
> Library API : 32.20200101-1<br>
<br>
And this further suggest fixes/32<br>
<br>
> I still wonder (an old habit as a software maintainer):<br>
> - did the compiler version used change recently?<br>
> - why does it crash only occasionally?<br>
<br>
As Klaas said, the adaptation field is optional in<br>
a transport stream packet.  To make things even<br>
more interesting, the adaptation field itself has<br>
multiple optional extensions.  If there is no<br>
adaptation field, or the packet is otherwise chosen<br>
not to be processed, one would not encounter<br>
the bug.<br>
<br>
Someone would have to go back and check the<br>
logs, but I suspect fixes/32 is the first packaged<br>
version update with the array changes which is<br>
why you are encountering the issue now.<br><br></blockquote><div>As Gary suspected, in fixes/31 there is still a C-style array so the problem should then never occur.</div><div>I confess I do not really understand why this abort happens.</div><div>Obtaining the adaptation field size is something that should happen very often as this is really in the inner part of transport stream processing.</div><div>As I understand C++, array access with .at(index_value) should do an array boundary check but access with [index_value] should not.</div><div>I do not know anything about the packaging so it is very well possible that somebody created a combination of compiler switches that does indeed check for array bounds on [index_value] accesses and that this is the first time somebody uses a fixes/32 package on Fedora....<br></div><div>Anyway, the patch does not create a problem in my test environment so it will be committed to master later today.</div><div><br></div><div>Klaas.</div><div><br></div><div><br></div><div> </div></div></div>