Just saw this on a workstation running Adélie, a Linux distribution built on musl libc. The frames do return (frame 3; finish shows a return code of -18), so this isn't a hang, but it seems to be stuck in a loop because every time I break in, it's the same exact stack trace. Computer was locked with kscreenlocker at 12 noon for a meeting; just after 14:00 it was unlocked and like this. The clock widget shows 13:04. No background applications were running beyond Firefox and Konsole, and it's a stock configuration of Plasma 5.12.2 on a Haswell IGP. I've taken a core dump but I'd rather not send it unless it would be useful to debugging; it's very large (5.2 GB). Note also the CPU and RAM usage of Plasma Shell and D-Bus: 10150 twilcox 7 0 5551.9m 2.857g 118.0 18.3 1524:13 R plasmashell 1751 twilcox 1 0 4897.7m 2.987g 23.3 19.1 1038:25 S dbus-daemon (gdb) bt full #0 0x00007f7e35134954 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/libQt5Core.so.5 No symbol table info available. #1 0x00007f7e3a38aa88 in KActivities::ActivitiesCache::currentActivityChanged (this=<optimized out>, _t1=...) at /usr/src/packages/user/kactivities/src/kactivities-5.43.0/build/src/lib/KF5Activities_autogen/EWIEGA46WW/moc_activitiescache_p.cpp:400 _a = {0x0, 0x55889a9f2c80} #2 0x00007f7e351350cb in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/libQt5Core.so.5 No symbol table info available. #3 0x00007f7e3a38783d in OrgKdeActivityManagerActivitiesInterface::CurrentActivityChanged (_t1=..., this=0x55881de20540) at /usr/src/packages/user/kactivities/src/kactivities-5.43.0/build/src/lib/activities_interface.moc:407 _a = {0x7ffda37f7dd0, 0x55881de20540} #4 OrgKdeActivityManagerActivitiesInterface::qt_static_metacall (_o=_o@entry=0x55881de20540, _c=_c@entry=QMetaObject::InvokeMetaMethod, _id=_id@entry=9, _a=_a@entry=0x7ffda37f7dd0) at /usr/src/packages/user/kactivities/src/kactivities-5.43.0/build/src/lib/activities_interface.moc:192 _t = 0x55881de20540 #5 0x00007f7e3a3886e9 in OrgKdeActivityManagerActivitiesInterface::qt_metacall (this=0x55881de20540, _c=QMetaObject::InvokeMetaMethod, _id=9, _a=0x7ffda37f7dd0) at /usr/src/packages/user/kactivities/src/kactivities-5.43.0/build/src/lib/activities_interface.moc:330 No locals. #6 0x00007f7e355900f2 in ?? () from /usr/lib/libQt5DBus.so.5 No symbol table info available. #7 0x00007f7e35135991 in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5 No symbol table info available. #8 0x00007f7e360d816c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 No symbol table info available. #9 0x00007f7e360dfa69 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5 No symbol table info available. #10 0x00007f7e35108980 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5 No symbol table info available. #11 0x00007f7e3510b75d in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQt5Core.so.5 No symbol table info available. #12 0x00007f7e3515f583 in ?? () from /usr/lib/libQt5Core.so.5 No symbol table info available. #13 0x00007f7e2fe1e77a in g_main_dispatch (context=0x7f7e3944c0c0) at gmain.c:3148 dispatch = 0x7f7e3515f570 prev_source = 0x0 was_in_call = 0 user_data = 0x0 callback = 0x0 cb_funcs = <optimized out> cb_data = <optimized out> need_destroy = <optimized out> source = 0x7f7e32d32240 current = 0x7f7e2c4abe00 i = 0 #14 g_main_context_dispatch (context=context@entry=0x7f7e3944c0c0) at gmain.c:3813 No locals. #15 0x00007f7e2fe1ea08 in g_main_context_iterate (context=context@entry=0x7f7e3944c0c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3886 max_priority = 0 timeout = 0 some_ready = 1 nfds = 8 allocated_nfds = <optimized out> fds = <optimized out> #16 0x00007f7e2fe1eabf in g_main_context_iteration (context=0x7f7e3944c0c0, may_block=1) at gmain.c:3947 retval = <optimized out> #17 0x00007f7e3515eb4f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 No symbol table info available. #18 0x00007f7e351068ea in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5 No symbol table info available. #19 0x00007f7e3510f934 in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5 No symbol table info available. #20 0x000055881d2d4be0 in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/packages/user/plasma-workspace/src/plasma-workspace-5.12.2/shell/main.cpp:166 app = <incomplete type> aboutData = {d = 0x55881dde3c40} service = <incomplete type>
Please include version of kde, frameworks, qt
I said Plasma 5.12.2; that includes all the KDE Plasma packages. KF 5.43.0. Qt 5.9.3. Kernel 4.14.19. Mesa 17.3.1.
I've just had this happen on my own workstation, while I was using it. There's pretty much no shared configuration between the two machines. The first machine: - Intel Haswell GPU - Konsole - KMahjongg - Firefox - Breeze decos - Had kscreenlocker running when it got stuck. - Only task manager and digital clock widgets. My workstation: - Radeon R9 270 - Pidgin - Konsole - Firefox - Kate - Aurora (plastik) decos - Was in active use when it got stuck. - Icon-only Task Manager, Thermal Monitor, Resources Monitor, Digital Clock widgets; CPU showed an even 50% load (which means 4 cores at 100%, since this is an 8 core Xeon) at time of lock. Packages on my system include: musl libc (x86_64) Version 1.1.19 qt5-qtbase-5.9.3-r1 plasma-desktop-5.12.2-r0 mesa-17.3.1-r1 libdrm-2.4.89-r2 Linux ciall 4.14.19-mc4-easy #1 SMP Sat Mar 10 08:42:58 UTC 2018 x86_64 GNU/Linux I have a core file from this lock as well. I left it for 30 minutes at 100% CPU usage before I took the core file then killed the process and restarted Plasma Shell. The backtrace was in QML this time: (gdb) bt #0 0x00007f63234d5c0b in QMetaObject::indexOfProperty(char const*) const () from /usr/lib/libQt5Core.so.5 #1 0x00007f632649cf65 in ?? () from /usr/lib/libQt5Qml.so.5 #2 0x00007f63264a427c in ?? () from /usr/lib/libQt5Qml.so.5 #3 0x00007f63263f439a in QV4::QObjectWrapper::findProperty(QV4::ExecutionEngine*, QQmlContextData*, QV4::String*, QV4::QObjectWrapper::RevisionMode, QQmlPropertyData*) const () from /usr/lib/libQt5Qml.so.5 #4 0x00007f63263f95e6 in QV4::QObjectWrapper::getQmlProperty(QQmlContextData*, QV4::String*, QV4::QObjectWrapper::RevisionMode, bool*, bool) const () from /usr/lib/libQt5Qml.so.5 #5 0x00007f63263f9b81 in QV4::QObjectWrapper::get(QV4::Managed const*, QV4::String*, bool*) () from /usr/lib/libQt5Qml.so.5 #6 0x00007f6326423731 in ?? () from /usr/lib/libQt5Qml.so.5 #7 0x00007f6326423798 in QV4::Runtime::method_getElement(QV4::ExecutionEngine*, QV4::Value const&, QV4::Value const&) () from /usr/lib/libQt5Qml.so.5 #8 0x00007f627acfa9cd in ?? () #9 0x00007f626d6f37e0 in ?? () #10 0x00007f630f6a1508 in ?? () #11 0x00007f626cab2a60 in ?? () #12 0x00007f630f6a1498 in ?? () #13 0x00007f626deb8500 in ?? () #14 0x00007f626deb8500 in ?? () #15 0x0000000000000000 in ?? () (gdb) c Continuing. ^C Thread 1 "plasmashell" received signal SIGINT, Interrupt. 0x00007f6326212780 in memcpy@plt () from /usr/lib/libQt5Qml.so.5 (gdb) bt #0 0x00007f6326212780 in memcpy@plt () from /usr/lib/libQt5Qml.so.5 #1 0x00007f632633addf in QV4::PersistentValueStorage::mark(QV4::ExecutionEngine*) () from /usr/lib/libQt5Qml.so.5 #2 0x00007f632622d28c in QV4::MemoryManager::mark() () from /usr/lib/libQt5Qml.so.5 #3 0x00007f632622dc64 in QV4::MemoryManager::runGC() () from /usr/lib/libQt5Qml.so.5 #4 0x00007f632622f8a8 in QV4::MemoryManager::allocString(unsigned long) () from /usr/lib/libQt5Qml.so.5 #5 0x00007f632631e7a1 in QV4::ExecutionEngine::newString(QString const&) () from /usr/lib/libQt5Qml.so.5 #6 0x00007f632632234b in QV4::ExecutionEngine::fromVariant(QVariant const&) () from /usr/lib/libQt5Qml.so.5 #7 0x00007f63263226e0 in QV4::ExecutionEngine::fromVariant(QVariant const&) () from /usr/lib/libQt5Qml.so.5 #8 0x00007f63263f8a00 in QV4::QObjectWrapper::getProperty(QV4::ExecutionEngine*, QObject*, QQmlPropertyData*, bool) () from /usr/lib/libQt5Qml.so.5 #9 0x00007f63263f967d in QV4::QObjectWrapper::getQmlProperty(QQmlContextData*, QV4::String*, QV4::QObjectWrapper::RevisionMode, bool*, bool) const () from /usr/lib/libQt5Qml.so.5 #10 0x00007f63263f9b81 in QV4::QObjectWrapper::get(QV4::Managed const*, QV4::String*, bool*) () from /usr/lib/libQt5Qml.so.5 #11 0x00007f6326423731 in ?? () from /usr/lib/libQt5Qml.so.5 #12 0x00007f6326423798 in QV4::Runtime::method_getElement(QV4::ExecutionEngine*, QV4::Value const&, QV4::Value const&) () from /usr/lib/libQt5Qml.so.5 #13 0x00007f627acfa9cd in ?? () #14 0x00007f626d5f2180 in ?? () #15 0x00007f630f6a1508 in ?? () #16 0x00007f626c406320 in ?? () #17 0x00007f630f6a1498 in ?? () #18 0x00007f626cc91860 in ?? () #19 0x00007f626cc91860 in ?? () #20 0x0000000000000000 in ?? () Unfortunately, since Qt 5 Declarative libraries are stripped even when Qt is configured with -no-strip, I can't get a reliable trace beyond that. (Perhaps there's a trick there that I'm unaware of; the libQt5Qml.so.5.9.3.debug file is just 2,528 bytes.)
Created attachment 111552 [details] KWin supportInformation from my workstation
Please reopen if you still have an issue in Qt5.11 *** This bug has been marked as a duplicate of bug 383828 ***
I am beginning to genuinely regret choosing KDE as our primary desktop environment. It feels like nobody in this entire project - or the Qt project for that matter - has any understanding of what "LTS" means. It means "long-term support" and it means you have to actually fix crashing/locking bugs like this *in the long term release*. I can take the patch from bug 383828 and backport it to Qt 5.9, but if I do that and it still happens, nobody will listen to me because it's not "Qt 5.11", it's "Qt 5.9 with the necessary patch". Time and time again this is all I get from the KDE team AND the Qt team. Stop using the name "LTS" if you aren't actually going to support releases for the long term. Qt 5.11 is not stable under some applications, it has many other bugs, it has no long guarantee of support which is what we *need*, and *it is not even released yet*. Requiring an UNRELEASED VERSION of a library for your Long Term Support release is completely UNACCEPTABLE. Yes, I realise Qt is completely useless, and they have been for years, and I've been dealing with bugs in Qt Declarative so long I've wondered why KDE ever migrated to QML (as I'm sure you lot have at some points as well), and they probably wouldn't even backport this to 5.9, but you could have at least *ASKED* them to. "The KDE® Community is a free software community dedicated to creating an open and user-friendly computing experience" -> directly from KDE.org. Telling people that their bugs are fixed if they go install a beta library that will crash in other horrible ways is not a user-friendly computing experience. The project goals of Adélie Linux, just like the project goals of KDE, is to bring truly libre computing to the masses. Our beta testers have praised our efforts at fighting to have good, stable releases across the board, and have said it has made us one of the most stable distros left. My vision is to have computing accessible to all, regardless of experience or ability. Using beta crap is not fulfiling that vision nor is it fulfiling the goals of the KDE Community. Now, I'm going to backport that patch to 5.9 this week, and then I'm going to push a Qt update, and then we'll see if it happens again. Hopefully it doesn't, but if it does, then this bug is being reopened, and no, "upgrade to a beta" is NOT an acceptable resolution.
Wow, so one of our other developers found hidden deep in a Gerrit thread that you lot actually *did* try to merge this fix in to 5.9 and Qt didn't let you. Well, that doesn't change any of what I said, but it does mean I mostly aimed it at the wrong project. That does explain why they make the comments so ridiculously hard to read in Qt's review system. I still feel that telling people to use Qt 5.11 to fix a bug instead of telling them to apply the patch to 5.9 /is/ unacceptable, but at least you tried to apply the patch directly to 5.9 upstream.
I encourage you to also read https://www.kde.org/code-of-conduct/ and be mindful for future correspondence.
I'm not sure you have the right information. Assuming we're talking about the QtV4::ObjectWrapper crash, the comment from Qt on my submission says: "Unfortunately 5.9 is closed for direct submissions, but I agree that it is 5.9 material. Once landed in 5.11 it can be cherry picked into 5.9."