- Status Closed
- Percent Complete
- 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
FS#60 - lightdm gtk greeter fails
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
Comments (12) Related Tasks (0/0)
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=0×0)
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=0×1)
–Type for more, q to quit, c to continue without paging–
at ../glib/glib/glib-unix.c:283
#11 0×00490145 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
Sounds related:
https://github.com/abrt/faf/issues/212 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.
15.11.2019 07:29
Reason for closing: Fixed
Additional comments about closing:
hotfixed in lightdm-1:1.28.0-1.3