[mythtv-users] Same error every day ~5:30 pm

Wed Nov 2 18:34:43 UTC 2022

On Wed, Nov 2, 2022 at 5:18 AM Klaas de Waal <klaas.de.waal at gmail.com>
wrote:

>
>
> On Wed, 2 Nov 2022 at 10:17, Stephen Worthington <stephen_agent at jsw.gen.nz>
> wrote:
>
>> On Wed, 2 Nov 2022 00:15:19 -0500, you wrote:
>>
>> >Hello,
>> >
>> >I'm getting the same seg fault every evening at 5:30 just as Myth is
>> about
>> >to start recording the evening news.
>> >
>> >Here's the backend log that appears relevant:
>> >
>> >Oct 17 17:29:00 zztop mythbackend: mythbackend[1474]: I Scheduler
>> >scheduler.cpp:2330 (HandleReschedule) Reschedule requested for PLACE
>> >PrepareToR
>> >ecord
>> >Oct 17 17:29:00 zztop mythbackend: mythbackend[1474]: I Scheduler
>> >scheduler.cpp:2444 (HandleReschedule) Scheduled 535 items in 0.2 = 0.00
>> >match +
>> >0.00 check + 0.16 place
>> >Oct 17 17:29:30 zztop mythbackend: mythbackend[1474]: I TVRecEvent
>> >tv_rec.cpp:1648 (HandlePendingRecordings) TVRec[20]: ASK_RECORDING 20 29
>> 0
>> >0
>> >Oct 17 17:29:30 zztop mythbackend: mythbackend[1474]: I TVRecEvent
>> >tv_rec.cpp:1648 (HandlePendingRecordings) TVRec[12]: ASK_RECORDING 12 29
>> 0
>> >0
>> >Oct 17 17:29:30 zztop mythbackend: mythbackend[1474]: I TVRecEvent
>> >tv_rec.cpp:1648 (HandlePendingRecordings) TVRec[11]: ASK_RECORDING 11 29
>> 0
>> >0
>> >Oct 17 17:29:30 zztop mythbackend: mythbackend[1474]: I TVRecEvent
>> >tv_rec.cpp:1648 (HandlePendingRecordings) TVRec[7]: ASK_RECORDING 7 29 0
>> 0
>> >Oct 17 17:29:30 zztop mythbackend: mythbackend[1474]: I ProcessRequest
>> >mythcommandlineparser.cpp:2920 (operator()) Qt: ASSERT failure in
>> QList<T>
>> >::operator[]: "index out of range", file
>> >/usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h, line 552
>> >Oct 17 17:29:30 zztop mythbackend: mythbackend[1474]: C CoreContext
>> >signalhandling.cpp:294 (handleSignal) Received Aborted: Code -6, PID
>> 1474,
>> >UI
>> >D 125, Value 0x00000000
>> >Oct 17 17:32:10 zztop mythbackend: mythbackend[162156]: C thread_unknown
>> >mythcommandlineparser.cpp:2901 (ConfigureLogging) mythbackend version: f
>> >ixes/32 [v32.0+fixes.202209121203.b6ef30288f~ubuntu20.04.1]
>> www.mythtv.org
>> >Oct 17 17:32:10 zztop mythbackend: mythbackend[162156]: C thread_unknown
>> >mythcommandlineparser.cpp:2905 (ConfigureLogging) Qt version: compile: 5
>> >.12.8, runtime: 5.12.8
>> >Oct 17 17:32:10 zztop mythbackend: mythbackend[162156]: I thread_unknown
>> >mythcommandlineparser.cpp:2907 (ConfigureLogging) Ubuntu 20.04.5 LTS (x8
>> >6_64)
>> >Oct 17 17:32:10 zztop mythbackend: mythbackend[162156]: N thread_unknown
>> >mythcommandlineparser.cpp:2909 (ConfigureLogging) Enabled verbose msgs:
>> >general
>> >Oct 17 17:32:10 zztop mythbackend: mythbackend[162156]: N thread_unknown
>> >logging.cpp:687 (logStart) Setting Log Level to LOG_INFO
>> >
>> >The recording is a daily recording where only one episode is kept,
>> >otherwise it's no different than many other recordings. I only do it in
>> >case we're not here to watch it live.
>> >
>> >Can anyone say this is a known bug?  what other relevant info would be
>> >needed for a quality bug report?
>>
>
> This is not a known bug. Please create a ticket, as it is then easier to
> keep track of and it is also easier to attach log files etc.
>
> It would be great if you can start mythbackend from gdb and then, when the
> segfault has happened, create a backtrace like this:
> gdb> bt full
> and attach the output to the ticket.
>
>
>> >
>> >I think I will try to delete the recording rule and create a new one, but
>> >am willing to let this go for a bit in case there's other debugging that
>> >might lead to a fix.
>> >
>> >Thanks,
>> >
>> >
>> >-- George
>>
>> What version of MythTV is it?  Is it a packaged version?  I thought
>> that the asserts were supposed to be turned off in the package builds.
>>
>
> Yes, asserts have historically only been used for development and
> debugging, and with good reason. IMHO TV's should continue playing and
> airplanes should continue to fly even if an array boundary limit is
> exceeded.
> However, apparently not everybody agrees with this as asserts have been
> switched on in recent RPMFusion builds for Fedora, see issue
> https://github.com/MythTV/mythtv/issues/589
>
> Klaas.
>
> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users at mythtv.org
>> http://lists.mythtv.org/mailman/listinfo/mythtv-users
>> http://wiki.mythtv.org/Mailing_List_etiquette
>> MythTV Forums: https://forum.mythtv.org
>>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

Hey all,

Sorry I neglected to state my backend version, it's  mythbackend version:
fixes/32 [v32.0+fixes.202210281018.ba52c13223~ubuntu20.04.1]

I guess it's a package version, it came as a update I guess on 10/28 or the
day after.

I'll let it go today and see if it happens again tonight (think it's
happened each evening lately). Should I add anything else to the logging
options? Pretty sure it's just logging default messages, but don't really
know which logging option would be appropriate to add for this...

I am not sure how to run the backend through gdb. Not sure I even have gdb
on my system unless it's there by default. (OK, just checked, it is) The
backend is started by the system, if there's a simple change I can make to
have it launch through gdb automatically I can do that for the next few
days, but then I'd need to know how to deal with the output... ??

I
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20221102/d55a8611/attachment.htm>