[mythtv-users] recent mythbackend crashing

[Klaas de Waal]

On Sat, 4 Jun 2022 at 16:00, Gary Buhrmaster <gary.buhrmaster at gmail.com>
wrote:

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

Klaas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20220604/ff364f1b/attachment.htm>