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

[John Pilkington]

On 25/07/2022 13:37, John Pilkington wrote:
> 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.
> 

And here's the result from 32Pre728.f35, today's master, which reports a 
decoding error at EOF, as usual, but completes with no crash.  The 
previously missing preview came up as usual in the Watch Recordings 
page, too.  The log in /tmp is 1.3 MB and looks routine.

 > John P
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mythcommflag_master.log
Type: text/x-log
Size: 771 bytes
Desc: not available
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20220725/e65c5993/attachment.bin>