Summary: | plasmashell gets in endless loop while screen is locked | ||
---|---|---|---|
Product: | [Plasma] plasmashell | Reporter: | A. Wilcox (awilfox) <awilfox> |
Component: | general | Assignee: | David Edmundson <kde> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | plasma-bugs, rdieter |
Priority: | NOR | ||
Version: | 5.12.2 | ||
Target Milestone: | 1.0 | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | KWin supportInformation from my workstation |
Description
A. Wilcox (awilfox)
2018-03-14 19:51:58 UTC
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." |