This happens very rarely. Probable scenario: At Plasma startup `pulseaudio -k` executed in the wrong moment. Since all MediaNode/MediaNodePrivate derived classes [1] seem to implement aboutToDeleteBackendObject() properly, maybe that virtual function is called before the derived class is constructed or after it is destroyed, which would be UB? Although the (only) call in FactoryPrivate::~FactoryPrivate() seems to operate on already well constructed MediaNodes. I'm not sure if this is the right thing to do, but to workaround this crash, maybe we could simply implement MediaNode::aboutToDeleteBackendObject() to make it non-pure virtual? Does it have a potential to hide any serious issues in the future? Application: plasma_session (plasma_session), signal: Aborted [KCrash Handler] #4 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49 #5 0x00007fba07614864 in __GI_abort () at abort.c:79 #6 0x00007fba07870951 in __gnu_cxx::__verbose_terminate_handler() () at ../../../../src/libstdc++-v3/libsupc++/vterminate.cc:95 #7 0x00007fba0787c47c in __cxxabiv1::__terminate(void (*)()) (handler=<optimized out>) at ../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:48 #8 0x00007fba0787c4e7 in std::terminate() () at ../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:58 #9 0x00007fba0787d245 in __cxxabiv1::__cxa_pure_virtual() () at ../../../../src/libstdc++-v3/libsupc++/pure.cc:50 #10 0x00007fba07f3acd5 in Phonon::MediaNodePrivate::deleteBackendObject() (this=0x7fb9f401a8a0) at ./phonon/medianode.cpp:78 #11 0x00007fba07f1d7b1 in Phonon::FactoryPrivate::~FactoryPrivate() (this=0x7fb9f40239f0, __in_chrg=<optimized out>) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h:543 #12 0x00007fba07f1da5d in Phonon::FactoryPrivate::~FactoryPrivate() (this=0x7fb9f40239f0, __in_chrg=<optimized out>) at ./phonon/factory.cpp:185 #13 0x00007fba07c601c2 in qt_call_post_routines() () at kernel/qcoreapplication.cpp:353 #14 0x00007fba07c60330 in QCoreApplication::~QCoreApplication() (this=0x7ffef5373410, __in_chrg=<optimized out>) at kernel/qcoreapplication.cpp:879 #15 0x000055a3cf9a7b99 in () #16 0x00007fba07616ca2 in __libc_start_main (main=0x55a3cf9a7b40, argc=1, argv=0x7ffef5373528, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffef5373518) at ../csu/libc-start.c:314 #17 0x000055a3cf9a7bee in _start () [Inferior 1 (process 5744) detached] System: Kubuntu 20.10 KDE Plasma Version: 5.19.5 KDE Frameworks Version: 5.74.0 Qt Version: 5.14.2 [1] https://invent.kde.org/libraries/phonon/-/tree/master/phonon
I rather think there's a data race in plasma_session. Specifically it creates a thread to run phonon but then never cleanly quits and/or synchronize that thread, leading to the crash you see where the global static cleanup on the initial thread wants to clean up all dangling phonon objects but that other thread has the objects in an unclear state. plasma_session needs to either: - synchronize the thread at some point - initialize and delete the phonon objects on the initial thread (though I guess that will trigger the PA waiting that the thread is trying to avoid) - use canberra instead of phonon (though I'm not sure that helps with the PA waiting either) - move the notification into a separate process Moving bug to plasma.
Is this still relevant in Plasma 6? Or in a PipeWire world?
Hasn't happened for a long time even in Plasma 5. And I no longer use PulseAudio either.