Mythfronted Segfault on exit

[jhoyt4]

• Platform: macOS 13, 14; Ubuntu (unkown;)

• MythTV version: v33

• Component: frontend

What steps will reproduce the bug?

Exit mythfrontend

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

Every exit for some users, occasionally for me

What is the expected behaviour?

Clean exit

What do you see instead?

Segfault

Additional information

Initially reported on the user mailing list

macOS segfault curtsey of James points to a QString issue
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 QtCore 0x10a271a58 0x10a268000 + 39512
1 QtCore 0x10a2d35fc QString::operator=(QString const&) + 32
2 mythfrontend 0x104295300 ExitPrompter::~ExitPrompter() + 64
3 QtWidgets 0x1096cdc88 QApplicationPrivate::notify_helper(QObject*, QEvent*) + 236
4 QtWidgets 0x1096ceaf8 QApplication::notify(QObject*, QEvent*) + 516
5 QtCore 0x10a38b21c QCoreApplication::notifyInternal2(QObject*, QEvent*) + 180
6 QtCore 0x10a38bf2c QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) + 516
7 QtCore 0x10a38b72c QCoreApplication::exec() + 148
8 mythfrontend 0x1041872b0 main + 18680

gdb output from Paul H. on self built Ubuntu indicates a QString issue as well:

Thread 1 "mythfrontend" received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=) at ./nptl/pthread_kill.c:44
Download failed: Invalid argument. Continuing without source file ./nptl/./nptl/pthread_kill.c.
44 ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3 0x00007ffff123c3b6 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4 0x00007ffff122287c in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007ffff12235a4 in __libc_message (fmt=fmt@entry=0x7ffff13b890f "%s\n") at ../sysdeps/posix/libc_fatal.c:150
#6 0x00007ffff129b677 in malloc_printerr (str=str@entry=0x7ffff13bb848 "corrupted size vs. prev_size while consolidating") at ./malloc/malloc.c:5651
#7 0x00007ffff129d888 in _int_free (av=0x7ffff13f6c80 <main_arena>, p=0x555556337b40, have_lock=) at ./malloc/malloc.c:4592
#8 0x00007ffff129fca3 in __GI___libc_free (mem=) at ./malloc/malloc.c:3367
#9 0x00007ffff6a66f0a in QTypedArrayData::deallocate(QArrayData*) (data=0x555556337b70) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qarraydata.h:239
#10 0x00007ffff6a666d7 in QString::~QString() (this=0x7ffff6da6158 Parse::kMythRSS, __in_chrg=) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:1311
#11 0x00007ffff123e566 in __cxa_finalize (d=0x7ffff6da0da0) at ./stdlib/cxa_finalize.c:82
#12 0x00007ffff6a64b77 in __do_global_dtors_aux () at /lib/libmythbase-34.so.34
#13 0x00007ffff7fc0ba0 in ()
#14 0x00007ffff7fc90e2 in _dl_call_fini (closure_map=0x7fffffffcfe0, closure_map@entry=0x7ffff7fc0ba0) at ./elf/dl-call_fini.c:43
#15 0x00007ffff7fcd1a8 in _dl_fini () at ./elf/dl-fini.c:114
#16 0x00007ffff123eb95 in __run_exit_handlers (status=0, listp=0x7ffff13f6840 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at ./stdlib/exit.c:111
#17 0x00007ffff123ecd0 in __GI_exit (status=) at ./stdlib/exit.c:141
#18 0x00007ffff1223a97 in __libc_start_call_main (main=main@entry=0x5555555d4842 <main(int, char**)>, argc=argc@entry=1, argv=argv@entry=0x7fffffffdce8) at ../sysdeps/nptl/libc_start_call_main.h:74
#19 0x00007ffff1223b49 in __libc_start_main_impl (main=0x5555555d4842 <main(int, char**)>, argc=1, argv=0x7fffffffdce8, init=, fini=, rtld_fini=, stack_end=0x7fffffffdcd8) at ../csu/libc-start.c:360
#20 0x00005555555c7ae5 in _start ()

[kmdewaal]

It would be helpful if this error can be reproduced with a debug build and then running under valgrind. Or something similar if that exists for MacOS.

It looks like the ExitPrompter destructor is causing the problems and it could just be that running under valgrind, e.g. "valgrind --track-origins=yes mythfrontend" gives the details needed.

The ExitPrompter has given similar problems in the past, but they were all fixed and the problem reported here cannot be reproduced by me now on Lnux/Fedora.

[jhoyt4]

Unfortunately, I've been unable to re-produce locally since upgrading my system to the latest macOS.

I just put out a cry for help on the mailing list where this was first reported. Hopefully someone is able to help out and get you the required outputs.

The commands to run (once valgrind is installed) are

valgrind --track-origins=yes /Applications/mythfrontend.app/Contents/MacOS/mythfrontend

There's also a native alternative leaks. They'd need to run:

export MallocStackLogging=1
leaks --atExit -- /Applications/mythfrontend.app/Contents/MacOS/mythfrontend

[jhoyt4]

Running leaks on my system with a clean exit yields the attached

leaksoutput.txt

[paul-h]

In my case the problem was an old out of date plugin was causing the crash on exit. Once I removed it the frontend shuts down normally.

Before I removed the rogue plugin I did try valgrind which after finding more than 1000 errors stopped reporting any more and seemed to give up. After removing the plugin there were still approx 500 errors reported but at least valgrind run to the end and there was no abort.

My guess is somehow if the FE attempts to load an old plugin it rightly fails to load it but something then causes some memory corruption which causes the aborts when the FE later tries to free the memory before shutting down.

[jhoyt4]

On Mon, Jan 15, 2024 at 6:56 AM Paul Harrison ***@***.***> wrote: In my case the problem was an old out of date plugin was causing the crash on exit. Once I removed it the frontend shuts down normally. Before I removed the rogue plugin I did try valgrind which after finding more than 1000 errors stopped reporting any more and seemed to give up. After removing the plugin there were still approx 500 errors reported but at least valgrind run to the end and there was no abort. My guess is somehow if the FE attempts to load an old plugin it rightly fails to load it but something then causes some memory corruption which causes the aborts when the FE later tries to free the memory before shutting down.

Thanks Paul! Unless someone else can recreate, I'm going to close out the ticket under the assumption it was a similar stale plugin. It can always be resurrected if someone can come up with a proper valgrind report. Klaus - thank you for taking a look!