Comment # 1 on bug 1160995 from Fabian Vogt

(In reply to GCC Da DiscoveryTechnologies from comment #0)
> Created attachment 827582 [details]
> Stack trace of crashed kscreenlocker_greet
> 
> Screen locker does not work for NIS accounts.
> 
> If I either manually lock the screen with the KDE controls or simply wait a
> few minutes until the screen locks itself, it crashes instead. The screen is
> black with a message telling that the screen locker is no longer working and
> how to resolve the problem from another console by unlocking it from the
> command line.
> 
> I am reproducing the problem with the command
> 
> /usr/lib64/libexec/kscreenlocker_greet --testing
> 
> for easier debugging.

The only code in kscreenlocker_greet calling into NIS is this:

> const KUser user;
> const QString fullName = user.property(KUser::FullName).toString();
> context->setContextProperty(QStringLiteral("kscreenlocker_userName"), fullName.isEmpty() ? user.loginName() : fullName);

Maybe it's the seccomp sandbox breaking it?
Can you try:

strace -e trace=seccomp -e inject=seccomp:error=EINVAL
/usr/lib64/libexec/kscreenlocker_greet --testing

> This results in
> 
> [...]
> Segmentation fault (core dumped)
> 
> It's not related to the NVIDIA driver I am using, because it's exactly the
> same without, using NOUVEAU instead.
> 
> Also it does not seem to be a KDE only problem, as I also can reproduce it
> on other desktops (Gnome, LXDE, XFCE and more).

Yes, the trace looks like a bug in libtirpc/glibc. Reassigning.

> Seems to be related to NIS. It only crashes when logged in with a NIS
> account. Local accounts don't have this problem.
> 
> systemd-coredump nicely collects the core dump (can provide this if
> required) and it also reports the stack trace into SYSLOG (see attachment).
> 
> Happy to supply more information useful for diagnosis.