Bug#946166: lightdm-gtk-greeter segfaults on hostname changes
Package: lightdm-gtk-greeter
Version: 2.0.6-1
This is a long-standing bug (see, e.g.,
https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1422794
https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1677058
https://bugzilla.redhat.com/show_bug.cgi?id=1399811
https://bugzilla.redhat.com/show_bug.cgi?id=1394472
) but still unfixed in buster (and upstream, I believe).
The symptom is a
lightdm-gtk-gre[920]: segfault at 10 ip 00007f011974ecc0 sp 00007ffe6f799768 error 4 in licairo.so.2.11600.0[7f01196eb000+cc000]
on the first login attempt after boot; the user ends up having to authenticate twice. seat0-greeter.log mentions
Invalid MIT-MAGIC-COOKIE-1 key
[Background] Failed to create root pixmap
in that order. Setting a static hostname for the machine suppresses the problem.
As far as I can tell, the immediate cause for the segfault is a missing check for src/greeterbackground.c:create_root_surface() returning NULL (which it does here, as evidenced by the "Failed to create root pixmap" message). One could add
if (!surface) return;
in the obvious place in greeter_background_save_xroot() to avoid segfaulting at this point. I wonder if one shouldn't also emit a more explicit hint ("has the hostname changed?" or "see <link to FAQ entry>") in the log when this happens.
This still won't address the Xauthority issue, though. /var/run/lightdm/root/:0, created by lightdm and not by the greeter, apparently contains a cookie for <hostname>/unix:0 which is not being updated when the hostname changes (e.g., due to DHCP activity after lightdm starts up). I'm filing this report against the greeter due to the segfault, but feel free to reassign/clone it to lightdm if need be.
I guess the reason this doesn't bite more people is that a static hostname is usually set at installation time. The machine on which I had this issue was installed from USB media, with the network connection non-functional during installation (due to a Thunderbolt support bug in the 4.19 kernel, fixed in 5.3.9 and hopefully in 4.19.82; but I digress) and ended up using localhost as the boot-time hostname.
Reply to: