• Status Closed
  • Percent Complete
    100%
  • Task Type Bug Report
  • Category Packages → Packages: Build-list
  • Assigned To No-one
  • Operating System i686
  • Severity Low
  • Priority Medium
  • Reported Version
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Archlinux32
Opened by Andreas Baumann - 10.01.2019
Last edited by Andreas Baumann - 20.01.2019

FS#60 - lightdm gtk greeter fails

Jan 10 12:55:01 arch32-staging systemd-coredump[894]: Process 892 (lightdm-gtk-gre) of user 620 dumped core.
                                                      
                                                      Stack trace of thread 892:
                                                      #0  0x00000000b712bb25 n/a (libglib-2.0.so.0)
                                                      #1  0x00000000b7120230 g_log_default_handler (libglib-2.0.so.0)
                                                      #2  0x00000000b712bd7d g_logv (libglib-2.0.so.0)
                                                      #3  0x00000000b712bf55 g_log (libglib-2.0.so.0)
                                                      #4  0x00000000b711267a g_thread_new (libglib-2.0.so.0)
                                                      #5  0x00000000b7132a1e n/a (libglib-2.0.so.0)
                                                      #6  0x00000000b7132a7a n/a (libglib-2.0.so.0)
                                                      #7  0x00000000b70e78d7 g_unix_signal_source_new (libglib-2.0.so.0)
                                                      #8  0x00000000b70ea3ef g_unix_signal_add_full (libglib-2.0.so.0)
                                                      #9  0x00000000b70ea463 g_unix_signal_add (libglib-2.0.so.0)
                                                      #10 0x00000000004dc145 main (lightdm-gtk-greeter)
                                                      #11 0x00000000b6c87a49 __libc_start_main (libc.so.6)
                                                      #12 0x00000000004de7f5 _start (lightdm-gtk-greeter)

Closed by  Andreas Baumann
20.01.2019 16:04
Reason for closing:  Fixed
Additional comments about closing:  

hotfixed in lightdm-1:1.28.0-1.3

Admin
Andreas Baumann commented on 19.01.2019 07:49

So, this happens when registering a signal handler: g_unix_signal_add.

Usually this points into the direction of ABI mismatches..

Admin
Andreas Baumann commented on 19.01.2019 08:07
[+0.83s] DEBUG: Session pid=3468: Running command /usr/bin/lightdm-gtk-greeter
[+0.83s] DEBUG: Creating shared data directory /var/lib/lightdm-data/lightdm
[+0.83s] DEBUG: Session pid=3468: Logging to /var/log/lightdm/seat0-greeter.log
[+1.45s] DEBUG: Seat seat0: Stopping; failed to start a greeter

the logfile is empty.

So, the question is, why doesn't the greeter start and segfault.

Admin
Andreas Baumann commented on 19.01.2019 09:19

rebuilt both lightdm-gtk-greeter and glib2 with debugging information (options=debug in PKGBUILD).

Now the stacktrace looks like:

#0  0xb7178b25 in _g_log_abort (breakpoint=1) at ../glib/glib/gmessages.c:554
554         G_BREAKPOINT ();
(gdb) bt
#0  0xb7178b25 in _g_log_abort (breakpoint=1) at ../glib/glib/gmessages.c:554
#1  0xb716d230 in g_log_default_handler
    (log_domain=0xb71b40d0 "GLib", log_level=6, message=0x78ee60 "creating thread 'gmain': Error creating thread: Resource temporarily unavailable", unused_data=0x0) at ../glib/glib/gmessages.c:3111
#2  0xb7178d7d in g_logv
    (log_domain=0xb71b40d0 "GLib", log_level=G_LOG_LEVEL_ERROR, format=0xb7207a67 "creating thread '%s': %s", args=0xbf85e91c "\262\320 \267") at ../glib/glib/gmessages.c:1350
#3  0xb7178f55 in g_log
    (log_domain=0xb71b40d0 "GLib", log_level=G_LOG_LEVEL_ERROR, format=0xb7207a67 "creating thread '%s': %s") at ../glib/glib/gmessages.c:1413
#4  0xb715f67a in g_thread_new (name=0xb720d0b2 "gmain", func=0xb7180b70 , data=0x0)
    at ../glib/glib/gthread.c:830
#5  0xb717fa1e in g_get_worker_context () at ../glib/glib/gmain.c:5888
#6  0xb717fa7a in ref_unix_signal_handler_unlocked (signum=15, signum=)
    at ../glib/glib/gmain.c:5224
#7  0xb71348d7 in _g_main_create_unix_signal_watch (signum=15) at ../glib/glib/gmain.c:5332
#8  0xb71348d7 in g_unix_signal_source_new (signum=15, signum=)
    at ../glib/glib/glib-unix.c:222
#9  0xb71373ef in g_unix_signal_add_full
    (priority=0, signum=15, handler=0x495f90 , user_data=0x1, notify=0x0)
    at ../glib/glib/glib-unix.c:252
#10 0xb7137463 in g_unix_signal_add (signum=15, handler=0x495f90 , user_data=0x1)
--Type  for more, q to quit, c to continue without paging--
    at ../glib/glib/glib-unix.c:283
#11 0x00490145 in main (argc=, argv=) at lightdm-gtk-greeter.c:2768
Admin
Andreas Baumann commented on 19.01.2019 09:44

creating thread 'gmain': Error creating thread: Resource temporarily unavailable

This is the interesting one. Why should creating a thread run out of resources? And which
resources?

Admin
Andreas Baumann commented on 19.01.2019 09:47

This is not by any chance an unhandled EAGAIN?

Admin
Andreas Baumann commented on 19.01.2019 10:04
[pid  6607] execve("/usr/bin/core_perl/plymouth", ["plymouth", "--ping"], 0xbfa9086c /* 22 vars */) = -1 ENOENT (No such file or directory)

this seems a collateral damage (aka hard-coded call to the bootup manager plymouth), not every
Linux distribution has a plymouth, so I hope, this is actually optional..
The -ping indicates, that plymouth is started with ping, to see whether it is around.
It doesn't seem to have something to do with our problem though..

There is a strace entry showing the greeter gets started:

[pid  6616] execve("/usr/bin/lightdm-gtk-greeter", ["/usr/bin/lightdm-gtk-greeter"], 0xf61510 /* 15 vars */) = 0

later the sighandler tries to open a new thread:

825       GThread *thread;
826
827       thread = g_thread_new_internal (name, g_thread_proxy, func, data, 0, &error);
828
829       if G_UNLIKELY (thread == NULL)
830         g_error ("creating thread '%s': %s", name ? name : "", error->message);
831
832       return thread;

So, if it runs out of resources here (due to a systemd limit, rlimit thing), this would
explain the startup issues..

There is also a suspicious:

[pid  6616] mmap2(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = -1 EAGAIN (Resource temporarily unavailable)

So, I check the rlimit settings used by systemd for login session..

Admin
Andreas Baumann commented on 20.01.2019 09:21
Admin
Andreas Baumann commented on 20.01.2019 10:37

mmh. why does lightdm-gtk-greeter work on 64-bit Archlinux?

Admin
Andreas Baumann commented on 20.01.2019 10:55

aha. the mmap works there.

Admin
Andreas Baumann commented on 20.01.2019 13:54

lightdm-gtk-greeter.c

mlockall (MCL_CURRENT | MCL_FUTURE);

commenting that out lets the mmap2 succeed.

As we deal with passwords, just disabling the locking is maybe not the best idea.

Incrementing the systemd limit in lightdm.conf LimitMEMLOCK=2684354560
didn't help at all.

Admin
Andreas Baumann commented on 20.01.2019 13:58

Locking the whole greeter with all GTK inside is maybe also not the wisest idea..

Admin
Andreas Baumann commented on 20.01.2019 14:03

LimitMEMLOCK=infinity in /lib/systemd/system/lightdm.service seemed so help.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing