Bug 229471 - x11/lightdm core dumps
Summary: x11/lightdm core dumps
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Ben Woods
Depends on:
Reported: 2018-07-02 08:11 UTC by Manuel Stühn
Modified: 2019-09-24 08:54 UTC (History)
5 users (show)

See Also:
woodsb02: maintainer-feedback+
woodsb02: merge-quarterly+


Note You need to log in before you can comment on or make changes to this bug.
Description Manuel Stühn 2018-07-02 08:11:19 UTC
Starting x11/lightdm on a recent FreeBSD CURRENT (r335821) leads to a core dump with signal 10. Analyzing the dump shows 
root@freebsd-t450:~ # gdb81 /usr/local/sbin/lightdm lightdm.core
GNU gdb (GDB) 8.1 [GDB v8.1 for FreeBSD]
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/sbin/lightdm...(no debugging symbols found)...done.
[New LWP 100728]
Core was generated by `lightdm'.
Program terminated with signal SIGBUS, Bus error.
#0  strncmp (
    s1=0x7a9cd970a65f427b <error: Cannot access memory at address 0x7a9cd970a65f427b>, s2=0x800721a9c "PATH", n=4) at /usr/src/lib/libc/string/strncmp.c:47
47			if (*s1 != *s2++)
(gdb) bt
#0  strncmp (s1=0x7a9cd970a65f427b <error: Cannot access memory at address 0x7a9cd970a65f427b>, s2=0x800721a9c "PATH", n=4) at /usr/src/lib/libc/string/strncmp.c:47
#1  0x00000008008c794e in strncmpeq (nameValue=0x7a9cd970a65f427b <error: Cannot access memory at address 0x7a9cd970a65f427b>, name=<optimized out>, nameLen=<optimized out>)
    at /usr/src/lib/libc/stdlib/getenv.c:146
#2  __findenv_environ (name=<optimized out>, nameLen=<optimized out>) at /usr/src/lib/libc/stdlib/getenv.c:197
#3  getenv (name=0x800721a9c "PATH") at /usr/src/lib/libc/stdlib/getenv.c:443
#4  0x000000080083e356 in _execvpe (name=0x80184b180 "/usr/local/bin/X", argv=0x800d3b6a0, envp=0x7fffffffe780) at /usr/src/lib/libc/gen/exec.c:279
#5  execvp (name=0x80184b180 "/usr/local/bin/X", argv=0x800d3b6a0) at /usr/src/lib/libc/gen/exec.c:144
#6  0x00000000002220b3 in ?? ()
#7  0x00000000002363ff in ?? ()
#8  0x0000000000225055 in ?? ()
#9  0x0000000000222d3d in ?? ()
#10 0x00000000002173e6 in ?? ()
#11 0x000000000021e9c8 in ?? ()
#12 0x0000000000216095 in ?? ()
#13 0x000000080026d000 in ?? ()
#14 0x0000000000000000 in ?? ()

I installed lightdm on a machine running 11.2, this runs fine.

All software is installed from url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest".

Please let me know, if further information is needed.
Comment 1 Matthias Petermann 2018-08-07 12:32:10 UTC
Hello Manuel,

thanks for reporting this issue. I experience the same core dump when running lightdm 1.24 (from pkg 2018Q3) built on FreeBSD 11.2.

Before, I had used lightdm 1.24 built on FreeBSD 11.1 on the same FreeBSD 11.2 system and it worked. 

Did you already go further with a solution or a workaround for this?

Kind regards,
Comment 2 Manuel Stühn 2018-08-09 10:20:10 UTC
Hi Matthias,
no, i did not track this further.

Comment 3 Alexander Mishin 2019-01-03 09:13:27 UTC
I tried to compile lightdm (and lightdm-gtk-greeter) with gcc8 (maybe another gcc version is acceptable too) instead of clang and the lightdm is working again.

For that I made just following changes to /etc/make.conf:
.if (!empty(.CURDIR:M/usr/ports/x11/lightdm*))
Comment 4 commit-hook freebsd_committer 2019-02-04 10:27:21 UTC
A commit references this bug:

Author: woodsb02
Date: Mon Feb  4 10:26:15 UTC 2019
New revision: 492108
URL: https://svnweb.freebsd.org/changeset/ports/492108

  x11/lightdm: Include pkg-message explaining how to fix LightDM coredumps

  PR:		229471
  Submitted by:	madpilot
  Reported by:	Manuel St?hn <freebsd@justmail.de>
  MFH:		2019Q1

Comment 5 Ben Woods freebsd_committer 2019-02-04 10:31:34 UTC
Hi Manuel, Matthias, Alexander - can you please test if the solution in this pkg-message fixes this issue for you?

LightDM needs the maximum amount of memory a daemon may request to be locked
into main memory using mlock(2) to be increased above the FreeBSD default.
Without doing this, LightDM will often crash when the service is started.
To increase this limit, run the following commands:
# sed -i '' -e 's/memorylocked=128M/memorylocked=256M/' /etc/login.conf
# cap_mkdb /etc/login.conf
Comment 6 commit-hook freebsd_committer 2019-02-04 10:36:33 UTC
A commit references this bug:

Author: woodsb02
Date: Mon Feb  4 10:35:47 UTC 2019
New revision: 492110
URL: https://svnweb.freebsd.org/changeset/ports/492110

  MFH: r492108

  x11/lightdm: Include pkg-message explaining how to fix LightDM coredumps

  PR:		229471
  Submitted by:	madpilot
  Reported by:	Manuel St?hn <freebsd@justmail.de>

  Approved by:	ports-secteam (miwi)

_U  branches/2019Q1/
Comment 7 Ben Woods freebsd_committer 2019-02-04 10:46:48 UTC
Closing this bug as this fixes it for me, but will re-open if anyone reports it doesn't work for them.

Ideally we would do one of the following:
1. change the default value of this login.conf parameter on FreeBSD so that it works by default with LightDM, or
2. modify the LightDM code so it doesn't require a higher limit on locked memory for daemons.

For item 1, I will open a discussion about this on the the FreeBSD-current mailing list. It might then be suitable in future releases of FreeBSD.

For item 2, the following line in the source code is responsible for this daemon locking all memory to prevent it from being paged to disk. The reason provided in the code comments is that this daemon deals with passwords, so prevent them from being written to disk in swap.

It might be possible for the code to only lock the memory which holds passwords. This should be reported and fixed upstream.
Comment 8 timp87 2019-09-24 08:54:48 UTC
(In reply to Ben Woods from comment #7)
Hello, Ben!
Have you had an opportunity to follow up your proposals and pass them to lightdm?

You've got into the same trouble in lightdm-gtk-greeter and created a merge request https://code.launchpad.net/~timp87/lightdm-gtk-greeter/opt-mem-lock/+merge/373117