| Summary: | [non-sse2] always crash initializing | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Felix Miata <mrmazda> |
| Component: | general | Assignee: | Kevin Kofler <kevin.kofler> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | crash | CC: | bhush94, kevin.kofler, notmart, plasma-bugs, rdieter |
| Priority: | NOR | ||
| Version: | 5.2.2 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Attachments: |
kcrash log
dmesg journalctl -b |
||
Created attachment 92071 [details]
dmesg
Created attachment 92072 [details]
journalctl -b
Not a Task Manager bug. Backtrace is strange and inconclusive. journalctl output has pretty much all the things crashing with something non-descript. Rex, seen this before at Fedora? No, I've not seen it before. Fwiw, fedora's i686 qt5-qtbase package is built with -no-sse2 , but since this is a non-default option, may not be well-tested either. pasting inline: Thread 1 (Thread 0xb603b800 (LWP 1010)): [KCrash Handler] #6 0xb7776be8 in __kernel_vsyscall () #7 0x426687f6 in __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:55 #8 0x4266a075 in __GI_abort () at abort.c:89 #9 0xb6561bac in QMessageLogger::fatal(char const*, ...) const () from /lib/libQt5Core.so.5 #10 0x48062e7d in QV8Engine::QV8Engine(QJSEngine*) () from /lib/libQt5Qml.so.5 #11 0x47e9f953 in QJSEngine::QJSEngine(QJSEnginePrivate&, QObject*) () from /lib/libQt5Qml.so.5 #12 0x47fbc1e4 in QQmlEngine::QQmlEngine(QObject*) () from /lib/libQt5Qml.so.5 #13 0x47a0102f in KDeclarative::QmlObject::QmlObject(QObject*) () from /lib/libKF5Declarative.so.5 #14 0x080ad477 in Osd::Osd(ShellCorona*) () #15 0x0809f02c in ShellCorona::ShellCorona(QObject*) () #16 0x080a926c in ShellManager::loadHandlers() () #17 0x080d0160 in ShellManager::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) () #18 0xb678d29b in QMetaCallEvent::placeMetaCall(QObject*) () from /lib/libQt5Core.so.5 #19 0xb67909a9 in QObject::event(QEvent*) () from /lib/libQt5Core.so.5 #20 0xb704e994 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib/libQt5Widgets.so.5 #21 0xb7054602 in QApplication::notify(QObject*, QEvent*) () from /lib/libQt5Widgets.so.5 #22 0xb675b235 in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /lib/libQt5Core.so.5 #23 0xb675dec1 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /lib/libQt5Core.so.5 #24 0xb675e4f4 in QCoreApplication::sendPostedEvents(QObject*, int) () from /lib/libQt5Core.so.5 #25 0xb67bab5f in postEventSourceDispatch(_GSource*, int (*)(void*), void*) () from /lib/libQt5Core.so.5 #26 0x429d5573 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #27 0x429d5955 in g_main_context_iterate.isra () from /lib/libglib-2.0.so.0 #28 0x429d5a27 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #29 0xb67bb020 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/libQt5Core.so.5 #30 0xb5dd26a7 in QPAEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/qt5/plugins/platforms/libqxcb.so #31 0xb6758137 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/libQt5Core.so.5 #32 0xb67585b4 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/libQt5Core.so.5 #33 0xb6760e3a in QCoreApplication::exec() () from /lib/libQt5Core.so.5 #34 0xb6a4e085 in QGuiApplication::exec() () from /lib/libQt5Gui.so.5 #35 0xb704b115 in QApplication::exec() () from /lib/libQt5Widgets.so.5 #36 0x0806ede8 in main () Argh, looks like Qt upstream has this hardcoded qFatal: http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/qml/qml/v8/qv8engine.cpp#n127 We must find a solution to this ASAP. As is, this package is NOT acceptable in Fedora. But the Fedora 22 KDE spin depends on it. So it turns out we already had a downstream fix for this issue (by disabling the JIT on non-SSE2 x86 and building a JIT- and SSE2-enabled version in /usr/lib/sse2), but 1. it was missing the hunk to disable this qFatal check and 2. it got disabled during the Qt 5.4 rebase. I'm fixing the issues now. Can you please try one of the following builds: Rawhide: http://koji.fedoraproject.org/koji/buildinfo?buildID=629862 Fedora 22: http://koji.fedoraproject.org/koji/buildinfo?buildID=629866 ? For non-Fedora people who are reading this: We use this patch: http://pkgs.fedoraproject.org/cgit/qt5-qtdeclarative.git/plain/qtdeclarative-opensource-src-5.4.1-no_sse2.patch and then build libQt5Qml both with SSE2 for /usr/lib/sse2 and without SSE2 for /usr/lib: http://pkgs.fedoraproject.org/cgit/qt5-qtdeclarative.git/plain/qt5-qtdeclarative.spec (Our qtbase is built with no_sse2 as well, and therefore the directories outside src/qml do not pick up any SSE2 flags with that setup.) So far, the comment 9 builds got F22 and Rawhide going on rv200 host m7ncd and F22 on nv11 host kt88b. Thank you for your feedback. (The problem with Rawhide on your nv11 machine appears to be an unrelated driver bug.) I'm going to close this here now as not a KDE issue. This is a Qt issue, thus UPSTREAM. Updated Fedora packages will enter updates shortly. https://admin.fedoraproject.org/updates/qt5-qtdeclarative-5.4.1-3.fc22 (and fc21 and fc20) submitted. On F22 host kt400 with rv250, 5.12.0/15.0.4 & qt5-qtdeclarative-4.4.2-2 does start without any crashing apparent. Thanks for confirming that this fixes it. It's sad that you and me seem to be the only ones caring about running current software on that generation of hardware. |
Created attachment 92070 [details] kcrash log I tried using the built-in abrt tool, but it's tiny little window with illegible and cutoff text is useless. Ever since Fedora removed KDE4 from its repos several months ago, this has been happening 100% consistently on 3 different machines with Athlon-class CPUs, hosts m7ncd (rv200), kt400 (rv250) and kt88b (nv11), using both Fedora 22 and Rawhide, whether logging in via sddm or kdm or using startx. Attached logs are from host kt88b. All my other installations have sse2, and KF5 works as expected on them.