After the last upgrade, the sddm greeter fails to display: Upon display-manager startup, a blank screen is displayed (on vt7) showing a mouse cursor, but there is no login greeter. A work-around is to use ctl-alt-f1 to bring up a console, log in as a normal user, and use for example startxfce4 to bring up the user's desktop (on the xfce4 window manager). There are no unexpected errors in Xorg.0.log: $ grep -F '(EE)' /var/log/Xorg.0.log (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 58.219] (EE) Failed to load module "fbdev" (module does not exist, 0) [ 63.330] (EE) AMDGPU(0): Failed to make import prime FD as pixmap: 22 Example output from running sddm-greeter from a terminal on xfce4: $ sddm-greeter --test-mode --theme /usr/share/sddm/themes/elarun [20:28:39.608] (II) GREETER: High-DPI autoscaling not Enabled [20:28:39.826] (II) GREETER: Reading from "/usr/share/xsessions/xfce.desktop" [20:28:39.827] (II) GREETER: Reading from "/usr/share/xsessions/Xsession.desktop" [20:28:39.830] (II) GREETER: Loading theme configuration from "/usr/share/sddm/themes/elarun/theme.conf" [20:28:39.873] (EE) GREETER: Socket error: "QLocalSocket::connectToServer: Invalid name" [20:28:40.618] (II) GREETER: Loading file:///usr/share/sddm/themes/elarun/Main.qml... Segmentation fault That lists in /var/log/messages: kernel: QQmlThread[25632]: segfault at 40 ip 00007f69d9e064e0 sp 00007f69ab7fcb90 error 4 in libQt5Qml.so.5.15.3[7f69d9cfd000+1c5000] kernel: Code: 66 89 44 24 06 8b 44 24 04 48 8b 54 24 08 64 48 2b 14 25 28 00 00 00 74 05 e8 bc 76 ef ff 48 83 c4 18 c3 90 41 54 85 f6 78 3f <4c> 8b 67 28 8b 47 18 41 8b 54 24 04 01 c2 39 f2 7e 2d 39 f0 7e 06 A second example for a kde greeter gives: $ sddm-greeter --test-mode --theme GentooAbstract_88yg-Sddm [20:33:17.794] (II) GREETER: High-DPI autoscaling not Enabled [20:33:17.892] (II) GREETER: Reading from "/usr/share/xsessions/xfce.desktop" [20:33:17.892] (II) GREETER: Reading from "/usr/share/xsessions/Xsession.desktop" [20:33:17.893] (II) GREETER: Loading theme configuration from "GentooAbstract_88yg-Sddm/theme.conf" [20:33:17.897] (EE) GREETER: Socket error: "QLocalSocket::connectToServer: Invalid name" [20:33:17.994] (II) GREETER: Loading file:GentooAbstract_88yg-Sddm/Main.qml... [20:33:18.339] (WW) GREETER: QObject: Cannot create children for a parent that is in a different thread. (Parent is QGuiApplication(0x7ffe42f91a38), parent's thread is QThread(0x55990584fda0), current thread is QThread(0x559905bf6cf0) [20:33:18.339] (WW) GREETER: QObject: Cannot create children for a parent that is in a different thread. (Parent is QGuiApplication(0x7ffe42f91a38), parent's thread is QThread(0x55990584fda0), current thread is QThread(0x559905bf6cf0) [20:33:18.389] (WW) GREETER: QObject: Cannot create children for a parent that is in a different thread. (Parent is QGuiApplication(0x7ffe42f91a38), parent's thread is QThread(0x55990584fda0), current thread is QThread(0x559905bf6cf0) [20:33:18.389] (WW) GREETER: QObject::installEventFilter(): Cannot filter events for objects in a different thread. Segmentation fault And that produces the error in /var/log/messages: kernel: QQmlThread[25753]: segfault at 40 ip 00007f04d40a64e0 sp 00007f04b1df6ef0 error 4 in libQt5Qml.so.5.15.3[7f04d3f9d000+1c5000] kernel: Code: 66 89 44 24 06 8b 44 24 04 48 8b 54 24 08 64 48 2b 14 25 28 00 00 00 74 05 e8 bc 76 ef ff 48 83 c4 18 c3 90 41 54 85 f6 78 3f <4c> 8b 67 28 8b 47 18 41 8b 54 24 04 01 c2 39 f2 7e 2d 39 f0 7e 06 FYI (equery): USE flags for dev-qt/qtdeclarative-5.15.3-r1: U I - - debug : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces - - gles2-only : Use GLES 2.0 or later instead of full OpenGL + + jit : Enable just-in-time compilation for improved performance. May prevent use of some PaX memory protection features in Gentoo Hardened. - - localstorage : Build the LocalStorage import for QtQuick (requires QtSql) - - test : Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently) + + vulkan : Enable support for Vulkan + + widgets : Enable QtWidgets support USE flags for x11-misc/sddm-0.18.1-r6: U I + + elogind : Enable session tracking via sys-auth/elogind + + pam : Add support for PAM (Pluggable Authentication Modules) - DANGEROUS to arbitrarily flip - - systemd : Enable use of systemd-specific libraries and features like socket activation or session tracking - - test : Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently) USE flags for dev-qt/qtconcurrent-5.15.3: U I - - debug : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces - - test : Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently) Has this any connection with https://bugs.gentoo.org/show_bug.cgi?id=838970 ? Thanks, Martin
This fail was still a problem for dev-qt/qtdeclarative-5.15.4 The compile options used for gcc as set in /etc/portage/make.conf included: CFLAGS="-march=native -mtune=native -Os -fomit-frame-pointer -pipe -fstack-protector-strong" CXXFLAGS="${CFLAGS}" Note that "gcc -Os" is set. The compile completes successfully. Meanwhile qtdeclarative fails with the segfault. Recompiling dev-qt/qtdeclarative but using "-O3" for the gcc optimization allows sddm to start up and operate without any segfault error in qtdeclarative. (Use of -O3 specifically for dev-qt/qtdeclarative can be set using /etc/portage/package.env)
ps, fyi: # gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/11.3.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-11.3.0/work/gcc-11.3.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/11.3.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.3.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.3.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.3.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/include/g++-v11 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/11.3.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 11.3.0 p4' --disable-esp --enable-libstdcxx-time --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp --disable-libada --disable-cet --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --without-zstd --enable-lto --without-isl --enable-default-pie --enable-default-ssp Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.3.0 (Gentoo 11.3.0 p4)
If you can, we really do need a backtrace so we can try to take this upstream. My inclination is (as asturm's PR does) to just filter -Os for now. I know that sucks but there's a limited number of hard bugs we can debug at any one time. Of course, if you can get a bt and we can repro it, it becomes easier.
(In reply to Sam James from comment #3) > If you can, we really do need a backtrace so we can try to take this > upstream. > > My inclination is (as asturm's PR does) to just filter -Os for now. I know > that sucks but there's a limited number of hard bugs we can debug at any one > time. Of course, if you can get a bt and we can repro it, it becomes easier. Alpine seem to have hit this too (they build most userland w/ -Os by default) and it hasn't gone anywhere: https://git.alpinelinux.org/aports/tree/community/qt5-qtdeclarative/APKBUILD#n33.
Thinking about it, I suppose we could bisect if it really did work with .3.
Forum thread dates this problem back to at least 5.15.2-r11: https://forums.gentoo.org/viewtopic-t-1146342.html
(In reply to Andreas Sturmlechner from comment #6) > Forum thread dates this problem back to at least 5.15.2-r11: > https://forums.gentoo.org/viewtopic-t-1146342.html correction: qtdeclarative-5.15.2-r14
(In reply to Sam James from comment #5) > Thinking about it, I suppose we could bisect if it really did work with .3. Someone really dedicated could try to test with vanilla-Qt (without Qt5PatchCollection, commenting out QT5_KDEPATCHSET_REV).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/qt.git/commit/?id=6522dcf23e8b1c0800bb39eb908db21193ea33ea commit 6522dcf23e8b1c0800bb39eb908db21193ea33ea Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2022-06-18 14:52:57 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2022-06-21 21:31:21 +0000 dev-qt/qtdeclarative: Replace -Os with -O2 Bug: https://bugs.gentoo.org/840861 Package-Manager: Portage-3.0.30, Repoman-3.0.3 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> dev-qt/qtdeclarative/qtdeclarative-5.15.5.9999.ebuild | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=91aa953df9cac2e18ad13a4108258419154fada3 commit 91aa953df9cac2e18ad13a4108258419154fada3 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2022-06-18 14:52:57 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2022-06-21 21:35:47 +0000 dev-qt/qtdeclarative: Replace -Os with -O2 Closes: https://bugs.gentoo.org/840861 Package-Manager: Portage-3.0.30, Repoman-3.0.3 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> dev-qt/qtdeclarative/qtdeclarative-5.15.5.ebuild | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
(In reply to Sam James from comment #3) > If you can, we really do need a backtrace so we can try to take this > upstream. > > My inclination is (as asturm's PR does) to just filter -Os for now. I know > that sucks but there's a limited number of hard bugs we can debug at any one > time. Of course, if you can get a bt and we can repro it, it becomes easier. Trying a recompile with: CFLAGS="-march=native -mtune=native -g3 -v -Q -Os -fomit-frame-pointer -pipe -fstack-protector-strong" set in /etc/portage/make.conf and... There is no segfault. For a wild guess: Are some inlines or macros getting stripped out by the -Os (and non-debug)...
