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

Tue Jul 26 14:03:46 UTC 2022

On 26/07/2022 13:13, John Pilkington wrote:
> On 26/07/2022 11:04, John Pilkington wrote:
>> 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
>>
>>
> 
> valgrind log from ffpmpeg-resync on another F35 box, using
> 
> valgrind mythcommflag --rebuild --file  <filename> 2>&1 | tee logfile
> 
> HTH

It was too big.  Compressed version instead.
> 
> John
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: valgrind_4core_ffresync.log.tar.gz
Type: application/gzip
Size: 8061 bytes
Desc: not available
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20220726/ce63ed24/attachment.gz>