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

[John Pilkington]

On 26/07/2022 01:09, Scott Theisen wrote:
> On 7/25/22 15:20, Paul Harrison wrote:
>> 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.
>>>
>>> John P
>>>
>>
>> That looks like same as the other abort in malloc_consolidate() you 
>> reported so it's consistent at least :) Any chance you can run it 
>> under valgrind?
>>
>>
>> Paul H.
> 
> I second running under valgrind.  "malloc_consolidate(): unaligned 
> fastbin chunk detected" and "double free or corruption (fasttop)" tell 
> me heap corruption is likely the culprit.
> 
> I did change the PMT exporting from the transport stream (used for 
> subtitles) to use AVBufferRef instead of a bare pointer.  In order to do 
> further harmonization, it now exports every PMT.  Also, I 
> converted/copied the functions to replace the deprecated AVPacket API.
> 
> Perhaps the extra, more frequent, heap turnover from the PMT export is 
> revealing a preexisting heap corruption issue, but without running under 
> valgrind we can't say where the corruption is occurring.
> 
> Regards,
> 
> Scott Theisen
> 
OK, I ran valgrind --leak-check=yes mythcommflag  --rebuild --file 
20001_20220725112900.ts

with master, and waited...    It feels quicker on a re-run but 
specifying the --log-file=filepath seems broken.  I have screen copies 
of around 80 KiB, but I suppose I should now reinstall the resync branch 
to get somethig more useful.

==185969== LEAK SUMMARY:
==185969==    definitely lost: 107,589 bytes in 62 blocks
==185969==    indirectly lost: 8,434 bytes in 140 blocks
==185969==      possibly lost: 672 bytes in 2 blocks
==185969==    still reachable: 98,484 bytes in 780 blocks
==185969==         suppressed: 0 bytes in 0 blocks