[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#842174: [sddm] sddm crashes when second session is started



¡Hola Johannes!

El 2016-11-04 a las 00:22 +0100, Johannes Zarl-Zierl escribió:
On Mittwoch, 26. Oktober 2016 19:48:20 CET Maximiliano Curia wrote:
To test my hypothesis I would need you to try starting a second session using a different display manager. If this fails in a similar way, then probably the video driver that you are using is the culprit, if not, something else is causing sddm to segfault and we would need some extra debugging information.

I tried installing xdm and lxdm, but plasma does not allow creating a second session with those display managers. How do I start a second session using another display manager? Is starting a session the same as just starting a second X server on another vt?

I think that xdm and lxdm don't support this, you'll need lightdm or gdm3 for starting a new session.

Given the results in your logs, it might be possible to reproduce the issue trying to start a second X by hand.

I went with the systemd-coredump route. See the attached coredump and the relevant syslog excerpt.

Ok, the log was more useful to me than the coredump, here is the corresponding backtrace:

(gdb) bt
#0  0x00007fea80000003 in ?? ()
#1  0x00007feade919b65 in QObject::connect(QObject const*, char const*, QObject const*, char const*, Qt::ConnectionType) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#2  0x0000000000430125 in SDDM::Auth::Private::setSocket (this=<optimized out>, socket=socket@entry=0x2578010) at /build/sddm-Wa20od/sddm-0.13.0/src/auth/Auth.cpp:141
#3  0x0000000000431d74 in SDDM::Auth::SocketServer::handleNewConnection (this=0x257af10) at /build/sddm-Wa20od/sddm-0.13.0/src/auth/Auth.cpp:93
#4  0x00007feade913bd9 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007feadec1c13f in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Network.so.5
#6  0x00007feade913bd9 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7  0x00007feade99036e in QSocketNotifier::activated(int, QSocketNotifier::QPrivateSignal) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x00007feade91fda2 in QSocketNotifier::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x00007feade8e643b in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x00007feade93c9ad in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x00007feadb2817d7 in g_main_dispatch (context=0x2571a30) at ././glib/gmain.c:3203
#12 g_main_context_dispatch (context=context@entry=0x2571a30) at ././glib/gmain.c:3856
#13 0x00007feadb281a40 in g_main_context_iterate (context=context@entry=0x2571a30, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ././glib/gmain.c:3929
#14 0x00007feadb281aec in g_main_context_iteration (context=0x2571a30, may_block=1) at ././glib/gmain.c:3990
#15 0x00007feade93c4ff in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x00007feade8e419a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x00007feade8ec99c in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x000000000041b686 in main (argc=1, argv=0x7ffda8b49f78) at /build/sddm-Wa20od/sddm-0.13.0/src/daemon/DaemonApp.cpp:138
(gdb)

The segfault seems to be caused because sddm is still trying to handle a new connection after the X died.

If the X dies sddm will simply try to restart it, but if it dies before the X outputs it's display number then sddm wrongly keeps the empty string as the display number and claims that the X has started. Then it's a time bomb and depending on luck, sddm might "correctly" try to restart X, or die trying to work with an invalid X display.

> Nov  3 23:49:59 mani sddm[856]: Adding new display on vt 8 ...
> Nov  3 23:49:59 mani sddm[856]: Display server starting...
> Nov  3 23:49:59 mani sddm[856]: Running: /usr/bin/X -nolisten tcp -auth /var/run/sddm/{39f61064-2ff9-4325-a3b8-5d87f89a3e31} -background none -noreset -displayfd 19 vt8
> Nov  3 23:50:00 mani sddm[856]: Running display setup script  "/usr/share/sddm/scripts/Xsetup"
> Nov  3 23:50:00 mani sddm[856]: Display server started.
> Nov  3 23:50:00 mani sddm[856]: Socket server starting...
> Nov  3 23:50:00 mani sddm[856]: Socket server started.
> Nov  3 23:50:00 mani sddm[856]: Greeter starting...
> Nov  3 23:50:00 mani sddm[856]: Adding cookie to "/var/run/sddm/{39f61064-2ff9-4325-a3b8-5d87f89a3e31}"
>
> Nov  3 23:50:00 mani sddm[856]: /usr/bin/xauth: (stdin):1:  bad "remove" command line
> Nov  3 23:50:00 mani sddm[856]: /usr/bin/xauth: (stdin):2:  bad "add" command line

This xauth output is caused by an invalid DISPLAY setting

> Nov  3 23:50:00 mani sddm[856]: Display server stopped.
> Nov  3 23:50:00 mani sddm[856]: Running display stop script  "/usr/share/sddm/scripts/Xstop"
> Nov  3 23:50:00 mani sddm[856]: Socket server stopping...
> Nov  3 23:50:00 mani sddm[856]: Socket server stopped.
> Nov  3 23:50:00 mani sddm[856]: Removing display "" ...

Note the empty string in the display number.

> Nov  3 23:50:00 mani sddm[856]: QProcess: Destroyed while process ("/usr/lib/x86_64-linux-gnu/sddm/sddm-helper") is still running.

This time it was lucky and sddm restarted X.

> Nov  3 23:50:08 mani sddm[856]: Adding new display on vt 8 ...
> Nov  3 23:50:08 mani sddm[856]: Display server starting...
> Nov  3 23:50:08 mani sddm[856]: Running: /usr/bin/X -nolisten tcp -auth /var/run/sddm/{cadc3e4a-8da3-4b39-9d1e-1c6d72818824} -background none -noreset -displayfd 19 vt8
> Nov  3 23:50:08 mani sddm[856]: Running display setup script  "/usr/share/sddm/scripts/Xsetup"
> Nov  3 23:50:08 mani sddm[856]: Display server started.
> Nov  3 23:50:08 mani sddm[856]: Socket server starting...
> Nov  3 23:50:08 mani sddm[856]: Socket server started.
> Nov  3 23:50:08 mani sddm[856]: Greeter starting...
> Nov  3 23:50:08 mani sddm[856]: Adding cookie to "/var/run/sddm/{cadc3e4a-8da3-4b39-9d1e-1c6d72818824}"
> Nov  3 23:50:08 mani sddm[856]: /usr/bin/xauth: (stdin):1:  bad "remove" command line
> Nov  3 23:50:08 mani sddm[856]: /usr/bin/xauth: (stdin):2:  bad "add" command line

Restarting didn't work.

> Nov  3 23:50:08 mani sddm[856]: Display server stopped.
> Nov  3 23:50:08 mani sddm[856]: Running display stop script  "/usr/share/sddm/scripts/Xstop"
> Nov  3 23:50:08 mani sddm[856]: Socket server stopping...
> Nov  3 23:50:08 mani sddm[856]: Socket server stopped.
> Nov  3 23:50:08 mani sddm[856]: Removing display "" ...
> Nov  3 23:50:08 mani sddm[856]: QProcess: Destroyed while process ("/usr/lib/x86_64-linux-gnu/sddm/sddm-helper") is still running.
> Nov  3 23:50:08 mani kernel: [   46.080910] sddm[856]: segfault at 7fea80000003 ip 00007fea80000003 sp 00007ffda8b493c8 error 14

I've produced a patch that handles reading an empty displaynumber (which means that the file was closed), sadly I can't test it, as I would need an X video driver that can't handle more than one display.

I'm attaching it, please let me know if you can test this.

I'll forward this information upstream.

Happy hacking,
--
"The sooner you start to code, the longer the program will take."
-- Roy Carlson
Saludos /\/\ /\ >< `/

Attachment: signature.asc
Description: PGP signature


Reply to: