- 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
Attached to Project: Archlinux32
Opened by Andreas Baumann - 10.01.2019
Last edited by Andreas Baumann - 20.01.2019
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:
20.01.2019 16:04
Reason for closing: Fixed
Additional comments about closing:
hotfixed in lightdm-1:1.28.0-1.3
So, this happens when registering a signal handler: g_unix_signal_add.
Usually this points into the direction of ABI mismatches..
the logfile is empty.
So, the question is, why doesn't the greeter start and segfault.
rebuilt both lightdm-gtk-greeter and glib2 with debugging information (options=debug in PKGBUILD).
Now the stacktrace looks like:
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?
This is not by any chance an unhandled EAGAIN?
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:
later the sighandler tries to open a new 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:
So, I check the rlimit settings used by systemd for login session..
Sounds related:
https://github.com/abrt/faf/issues/212
mmh. why does lightdm-gtk-greeter work on 64-bit Archlinux?
aha. the mmap works there.
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.
Locking the whole greeter with all GTK inside is maybe also not the wisest idea..
LimitMEMLOCK=infinity in /lib/systemd/system/lightdm.service seemed so help.