Qt: ASSERT failure in QList<T>::operator[]: "index out of range"

[nikarul]

• Platform:
  Ubuntu 22.04 with XFCE desktop.
  Linux brinstar.digitalbytes.net 5.4.0-135-generic #152-Ubuntu SMP Wed Nov 23 20:19:22 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

• MythTV version:
  MythTV Version : v32.0+fixes.20220325.f69ce764b7-0ubuntu1
  MythTV Branch : fixes/32
  Network Protocol : 91
  Library API : 32.20200101-1
  QT Version : 5.15.2
  Options compiled in:
  linux profile use_hidesyms using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_bindings_php using_dvb using_firewire using_frontend using_hdhomerun using_satip using_vbox using_ceton using_joystick_menu using_libcec using_libcrypto using_gnutls using_libdns_sd using_libfftw3 using_libxml2 using_lirc using_mheg using_opengl using_egl using_qtwebkit using_qtscript using_qtdbus using_taglib using_v4l2 using_v4l2prime using_x11 using_system_libbluray using_system_libudfread using_systemd_notify using_systemd_journal using_drm using_bindings_perl using_bindings_python using_bindings_php using_freetype2 using_mythtranscode using_opengl using_egl using_drm using_vaapi using_nvdec using_vdpau using_ffmpeg_threads using_mheg using_libass using_libxml2 using_libmp3lame

• Package version:
  mythtv-backend 2:32.0+fixes.20220325.f69ce764b7-0ubuntu1 amd64

• Component:
  mythbackend

What steps will reproduce the bug?

I upgraded from Ubuntu 20.04 with MythTV v31 to 22.04 with MythTV v32, and now when a scheduled recording starts, the backend appears to crash and restart. Here's the relevant line from mythbackend.log:

Jan 5 06:58:31 myth mythbackend: mythbackend[9191]: I ProcessRequest mythcommandlineparser.cpp:2920 (operator()) Qt: ASSERT failure in QList::operator[]: "index out of range", file /usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h, line 579

How often does it reproduce? Is there a required condition?

It occurs shortly before a scheduled recording starts. I'm not sure if its every time, but its often.

What is the expected behaviour?

Backend does not crash.

What do you see instead?

This manifests on the frontend by losing the backend connection and getting kicked out of any live TV (no surprise there).

Additional information

This did not occur with v31 or earlier. Recordings do not appear to be affected, the backend restarts in time to begin the scheduled recording. Here is my full backend log:

mythbackend.log

[kmdewaal]

Can you please update to the latest v32 and check if the problem still exists?
I am not a package user but, as I understand it, upgrading can be done by installing directly from the MythTV updates repository, as described in https://www.mythtv.org/wiki/Mythbuntu, or the easy way via the MythBuntu Control Panel, as described in https://www.mythtv.org/wiki/Mythbuntu_Control_Panel.

[nikarul]

Done. It's been crashing pretty regularly on the 7 AM recording, so we'll see how it does tomorrow morning. In the meantime, here's the new version:

MythTV Version : v32.0+fixes.202301091618.e677dd354f~ubuntu22.04.1
MythTV Branch : fixes/32
Network Protocol : 91
Library API : 32.20200101-1
QT Version : 5.15.3
Options compiled in:
linux profile use_hidesyms using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_bindings_php using_dvb using_firewire using_frontend using_hdhomerun using_satip using_vbox using_ceton using_joystick_menu using_libcec using_libcrypto using_gnutls using_libdns_sd using_libfftw3 using_libxml2 using_lirc using_mheg using_opengl using_egl using_qtwebkit using_qtscript using_qtdbus using_taglib using_v4l2 using_v4l2prime using_x11 using_system_libbluray using_system_libudfread using_systemd_notify using_systemd_journal using_drm using_bindings_perl using_bindings_python using_bindings_php using_freetype2 using_mythtranscode using_opengl using_egl using_drm using_vaapi using_nvdec using_vdpau using_ffmpeg_threads using_mheg using_libass using_libxml2 using_libmp3lame

[nikarul]

Unfortunately, the new build appears to have the same crash. I've attached a new backend log from the new version. I also have a truncated core dump I can provide. I can also try to get a full (or at least less truncated) core dump if that be useful.

mythbackend.log.gz

[kmdewaal]

OK, so the latest fixes/32 also fails. The log shows lots of assert failures but also other unxpected program exits.
When mythbackend has crashed and created a core dump, can you please provide the stacktrace from that core dump?
This can be done with the command
coredumpctl gdb
and then do
thread apply all bt full
to give the backtrace of all threads.
If the core dump is too small then the command
ulimit -c unlimited
might fix that for the next core dump.

Alternatively, if you can run mythbackend under gdb (the binary is mythbackend.real in Ubuntu distributions) then you can set a breakpoint on qFatal by doing the following:

gdb mythbackend.real
b qFatal

and when it breaks then do the
bt full
and
thread apply all bt full
while we are at it.

N.B. A problem with the distribution packages is that they are compiled with full optimization and that they seem to have no debug information anymore so the backtrace gives only limited information.
It might be necessary to do a compile from source but we will save that for later.

[One-ders]

I just filed a duplicate to this one.

[nikarul]

Apologies that I haven't gotten back to this yet. There's no debug info available in the packages for the PPAs, so I've got a locally built version of MythTV with debug info enabled, but I haven't had time to install it on my backend server and test it. I'll report back once I'm able to get some useful stack traces.

[kmdewaal]

The bug is now fixed and committed to master and to fixes/32.
Thanks for reporting and helping the investigation.

Klaas.