[mythtv] Call for testing branch devel/ffmpeg-resync (mpegts-harmonize)

[John Pilkington]

On 25/07/2022 12:03, Klaas de Waal wrote:
> FYI, Fedora in itself does not cause the additional boundary checks on 
> std::array.
> This happens in the RPMFusion package builds because they define a 
> special GCC preprocessor symbol -D_GLIBCXX_ASSERTIONS.
> If you define this symbol in an Ubuntu build then I expect it will do 
> the boundary checking as well.
> The backtrace itself does not indicate a boundary check so I think this 
> is a different problem.
> 
> Klaas.
> 
> 
> On Mon, 25 Jul 2022 at 12:39, Paul Harrison <mythtv at mythqml.net 
> <mailto:mythtv at mythqml.net>> wrote:
> 
>     On 24/07/2022 18:42, John Pilkington wrote:
> 
>      > On 24/07/2022 16:57, Paul Harrison wrote:
>      >>
>      >> I wonder if this could be related to the other Fedora crash
>     reported
>      >> recently in Issue #589. It seems by default there is more bounds
>      >> checking being done in Fedora which can cause aborts.
>      >>
>      >> https://github.com/MythTV/mythtv/issues/589
>     <https://github.com/MythTV/mythtv/issues/589>
>      >>
>      >>
>      >> If you can get a backtrace it may be possible to track down
>     where the
>      >> problem is.
>      >>
>      >>
>      >> Paul H.
>      >
>      > It's certainly true that my update from the
>      > devel/ffmpeg-resync/morelogs branch to yesterday's
>     devel/ffmpeg-resync
>      > was accompanied by what appeared to be a big update of F35,
>     icluding a
>      > new kernel.
>      >
>      > gdb output attached.
>      >
>      >
> 
>     The backtrace appears to show the abort on shutting down the preview
>     generator which is consistent with the abort on playback end. It looks
>     like something has changed that is causing an abort when closing
>     playback down. The crash is in FFMpeg but it could be something we are
>     doing to cause it. Maybe Scott has a better idea what has changed to
>     cause this. It could also be that the bug was already there in previous
>     versions and the extra bounds checking in Fedora is highlighting the
>     problem.
> 
> 
>     Can you reproduce this if you revert back to plain master without the
>     ffmpeg-resync changes?
> 
> 
>     Try to keep your testing as simple as possible. If you have to use
>     external scripts then that is not really helpful. We need to be able to
>     reproduce the problem in stock MythTV if possible.
> 
> 
>     Paul H.
> 

The last builds I have of master before resync are  32Pre509 from 3 
July.  There was no hint of this then, or with resyncs before the batch 
on 23 July.  I don't expect difficulty in building current master for 
F35, but I haven't done it yet.

Attached is gdb output for mythcommflag --rebuild on a BBC ONE DVB-T raw 
fragment.

John P
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdbcommflag.log
Type: text/x-log
Size: 20796 bytes
Desc: not available
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20220725/95ad2651/attachment.bin>
-------------- next part --------------
### Run with $ gdb mythcommflag -x ~/gdbcommands
#
#
handle SIGPIPE nostop noprint
handle SIG33 nostop noprint
set logging enabled on
set pagination off
set breakpoint pending on
break qFatal  
set args --rebuild --chanid 20001 --starttime 20220725112900
run
thread apply all bt full
set logging enabled off