[mythtv] Call for testing branch devel/ffmpeg-resync (mpegts-harmonize)
mythtv at mythqml.net
Mon Jul 25 19:20:15 UTC 2022
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.
>> 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
>> >> 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
>> >> 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
>> > 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
>> 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
>> versions and the extra bounds checking in Fedora is highlighting the
>> Can you reproduce this if you revert back to plain master without
>> 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
More information about the mythtv-dev