Bug 384005 - With Latest Nvidia Drivers (384.69), Kscreenlocker has a segfault
Summary: With Latest Nvidia Drivers (384.69), Kscreenlocker has a segfault
Status: RESOLVED FIXED
Alias: None
Product: kscreenlocker
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Neon Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL: https://devtalk.nvidia.com/default/to...
Keywords:
: 383981 384064 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-08-25 13:44 UTC by Pranav Sharma
Modified: 2017-10-21 20:44 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
opensuse user's post (121 bytes, text/plain)
2017-08-25 13:44 UTC, Pranav Sharma
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pranav Sharma 2017-08-25 13:44:24 UTC
Created attachment 107514 [details]
opensuse user's post

With the latest version of nvidia drivers (384.69), and the latest version of kscreenlocker (5.10.5), there is a segfault whenever the screen locks, requiring the user to unlock their session via loginctl. I have observed this on KDE neon, and it seems that a user on opensuse tw has experienced this as well.
Comment 1 Martin Flöser 2017-08-25 14:30:37 UTC
We need the backtrace of the crash to further investigation.
Comment 2 Pranav Sharma 2017-08-25 15:49:52 UTC
I can't seem to generate a backtrace using gdb. Maybe someone else can generate one.


pranav@pranav-desktop:~$ gdb /usr/lib/x86_64-linux-gnu/libexec/kscreenlocker_greet
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 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-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/x86_64-linux-gnu/libexec/kscreenlocker_greet...Reading symbols from /usr/lib/debug/.build-id/d7/67db8acfe60524e372900c4e7bed9612548377.debug...done.
done.
(gdb) r --testing
Starting program: /usr/lib/x86_64-linux-gnu/libexec/kscreenlocker_greet --testing
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Cannot find user-level thread for LWP 8122: generic error
(gdb)
Comment 3 Pranav Sharma 2017-08-25 15:56:19 UTC
nevermind, i forgot to start gdb with sudo. It seems to be in nvidia's gl.

Starting program: /usr/lib/x86_64-linux-gnu/libexec/kscreenlocker_greet --testing
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
[New Thread 0x7fffe7aa8700 (LWP 8383)]
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
[New Thread 0x7fffe5936700 (LWP 8385)]
[New Thread 0x7fffe5135700 (LWP 8391)]
QObject: Cannot create children for a parent that is in a different thread.
(Parent is ScreenLocker::UnlockApp(0x7fffffffe3b0), parent's thread is QThread(0x635c40), current thread is QThread(0x8b8eb0)
QObject::installEventFilter(): Cannot filter events for objects in a different thread.
QObject: Cannot create children for a parent that is in a different thread.
(Parent is ScreenLocker::UnlockApp(0x7fffffffe3b0), parent's thread is QThread(0x635c40), current thread is QThread(0x8b8eb0)
org.kde.kcoreaddons: Failed to establish shared memory mapping, will fallback to private memory -- memory usage will increase
QObject: Cannot create children for a parent that is in a different thread.
(Parent is ScreenLocker::UnlockApp(0x7fffffffe3b0), parent's thread is QThread(0x635c40), current thread is QThread(0x8b8eb0)
QObject::installEventFilter(): Cannot filter events for objects in a different thread.
Locked at 1503676470
[New Thread 0x7fffd4d5a700 (LWP 8392)]

Thread 5 "QSGRenderThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffd4d5a700 (LWP 8392)]
0x00007fffdedffc02 in ?? () from /usr/lib/nvidia-384/libnvidia-glcore.so.384.69
(gdb)
Comment 4 Pranav Sharma 2017-08-25 16:03:18 UTC
(gdb) bt
#0  0x00007fffdedffc02 in ?? () from /usr/lib/nvidia-384/libnvidia-glcore.so.384.69
#1  0x00007fffdf0ca9ba in ?? () from /usr/lib/nvidia-384/libnvidia-glcore.so.384.69
#2  0x00007fffdef953da in ?? () from /usr/lib/nvidia-384/libnvidia-glcore.so.384.69
#3  0x00007fffdefab2d4 in ?? () from /usr/lib/nvidia-384/libnvidia-glcore.so.384.69
#4  0x00007fffdef99bce in ?? () from /usr/lib/nvidia-384/libnvidia-glcore.so.384.69
#5  0x00007ffff5f0b681 in QSGBatchRenderer::Renderer::renderMergedBatch(QSGBatchRenderer::Batch const*) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#6  0x00007ffff5f0bf8d in QSGBatchRenderer::Renderer::renderBatches() () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#7  0x00007ffff5f11909 in QSGBatchRenderer::Renderer::render() () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#8  0x00007ffff5f0209f in QSGRenderer::renderScene(QSGBindable const&) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#9  0x00007ffff5f0257b in QSGRenderer::renderScene(unsigned int) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#10 0x00007ffff5f3dd2e in QSGDefaultRenderContext::renderNextFrame(QSGRenderer*, unsigned int) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#11 0x00007ffff5f97b04 in QQuickWindowPrivate::renderSceneGraph(QSize const&) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#12 0x00007ffff5f4715e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#13 0x00007ffff5f4b8dc in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#14 0x00007ffff4e28989 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x00007ffff39966ba in start_thread (arg=0x7fffd4d5a700) at pthread_create.c:333
#16 0x00007ffff47353dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb)
Comment 5 Pranav Sharma 2017-08-25 16:06:22 UTC
(gdb) thread apply all backtrace

Thread 5 (Thread 0x7fffd4d5a700 (LWP 8635)):
#0  0x00007fffdedffc02 in ?? () from /usr/lib/nvidia-384/libnvidia-glcore.so.384.69
#1  0x00007fffdf0ca9ba in ?? () from /usr/lib/nvidia-384/libnvidia-glcore.so.384.69
#2  0x00007fffdef953da in ?? () from /usr/lib/nvidia-384/libnvidia-glcore.so.384.69
#3  0x00007fffdefab2d4 in ?? () from /usr/lib/nvidia-384/libnvidia-glcore.so.384.69
#4  0x00007fffdef99bce in ?? () from /usr/lib/nvidia-384/libnvidia-glcore.so.384.69
#5  0x00007ffff5f0b681 in QSGBatchRenderer::Renderer::renderMergedBatch(QSGBatchRenderer::Batch const*) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#6  0x00007ffff5f0bf8d in QSGBatchRenderer::Renderer::renderBatches() () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#7  0x00007ffff5f11909 in QSGBatchRenderer::Renderer::render() () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#8  0x00007ffff5f0209f in QSGRenderer::renderScene(QSGBindable const&) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#9  0x00007ffff5f0257b in QSGRenderer::renderScene(unsigned int) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#10 0x00007ffff5f3dd2e in QSGDefaultRenderContext::renderNextFrame(QSGRenderer*, unsigned int) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#11 0x00007ffff5f97b04 in QQuickWindowPrivate::renderSceneGraph(QSize const&) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#12 0x00007ffff5f4715e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#13 0x00007ffff5f4b8dc in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#14 0x00007ffff4e28989 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x00007ffff39966ba in start_thread (arg=0x7fffd4d5a700) at pthread_create.c:333
#16 0x00007ffff47353dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 4 (Thread 0x7fffe5135700 (LWP 8634)):
#0  0x00007ffff472970d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007ffff122b38c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff122b49c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff505192f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x00007ffff4ffa7ca in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007ffff4e23cd4 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x00007ffff5c7d0c5 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#7  0x00007ffff4e28989 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x00007ffff39966ba in start_thread (arg=0x7fffe5135700) at pthread_create.c:333
#9  0x00007ffff47353dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 3 (Thread 0x7fffe5936700 (LWP 8632)):
#0  0x00007ffff472970d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007ffff122b38c in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff122b49c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff505192f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x00007ffff4ffa7ca in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007ffff4e23cd4 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x00007ffff7f57b75 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#7  0x00007ffff4e28989 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x00007ffff39966ba in start_thread (arg=0x7fffe5936700) at pthread_create.c:333
#9  0x00007ffff47353dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 2 (Thread 0x7fffe7aa8700 (LWP 8630)):
#0  0x00007ffff472970d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007ffff41c9c62 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x00007ffff41cb8d7 in xcb_wait_for_event () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x00007fffeae72329 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#4  0x00007ffff4e28989 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007ffff39966ba in start_thread (arg=0x7fffe7aa8700) at pthread_create.c:333
---Type <return> to continue, or q <return> to quit---
Comment 6 Martin Flöser 2017-08-25 19:31:09 UTC
Unfortunately a rather common regression in the latest nvidia driver. We also have lots of such reports for KWin. Looks like anything with QtQuick could be affected.

Not much we can do, please report to NVIDIA.
Comment 7 Pranav Sharma 2017-08-25 20:52:49 UTC
Will post on nvidia's forum. Thanks for taking a look / helping out with this issue.
Comment 8 Martin Flöser 2017-08-27 07:17:53 UTC
*** Bug 384064 has been marked as a duplicate of this bug. ***
Comment 9 Scott 2017-08-27 17:57:06 UTC
(In reply to Martin Flöser from comment #8)
> *** Bug 384064 has been marked as a duplicate of this bug. ***

I'm coming from that bug report. I can confirm that rolling the nVidia driver back from 384.69 to 381.22 fixes the problem for me.
Comment 11 Martin Flöser 2017-08-30 16:36:45 UTC
I got some information from NVIDIA: the root problem is our seccomp filter which disallows write access. This results in NVIDIA not being able to open required files for writing in the /dev/ directory and that is the root cause for the crash.

We were aware that disallowing write might cause problems and have a "hack" there to first open an OpenGL context in the hope that this triggers everything the driver needs. This seems to have been overly optimistic (it worked when we tested it).

I'm currently working on a bug fix which can detect NVIDIA and disable the too restrictive seccomp rules. This of course means the sandbox is not fully functional any more on NVIDIA.
Comment 12 Martin Flöser 2017-08-30 16:51:49 UTC
Workaround at https://phabricator.kde.org/D7616

If anyone who is affected could test this, it would be highly appreciated as I don't have any possibility to test the change.
Comment 13 Pranav Sharma 2017-08-30 17:30:09 UTC
I could try to test it, but I don't know how to build from source / install. Maybe I could wait for neon git to build the package and then install that deb on my current install?
Comment 14 Pranav Sharma 2017-08-30 19:32:41 UTC
With the patch, there is no more crash: https://drive.google.com/file/d/0B96RwvX3UE0GU2h3YmdvbVBzTW8/view?usp=sharing

Here is the deb package I built, if anyone else wants to test on their system: https://drive.google.com/file/d/0B96RwvX3UE0GanBFSEUzdzJwSUE/view?usp=sharing

I just rebuilt the deb from the neon repos with the diff from prefabricator as a patch. Any idea when this fix can be shipped out to users? Also thanks so much for helping me with this issue.

(Note to self, build-deps is icky and cant be undone, use mk-build-deps instead)
Comment 15 Martin Flöser 2017-08-31 15:50:07 UTC
Git commit 2136a38d88c8d0d7be67fe0c6c0870e53a6f7bc6 by Martin Flöser.
Committed on 30/08/2017 at 16:50.
Pushed by graesslin into branch 'Plasma/5.10'.

Don't dissallow open with write flag syscall on NVIDIA

Summary:
The latest NVIDIA driver crashes the greeter due to our seccomp enabled
sandbox being too restrictive. The driver is now opening files for
writing after our dummy context got created and this causes a crash. In
order to provide our users a working system again we better disable the
seccomp rule for NVIDIA users for the time being.

To detect whether an NVIDIA driver is used I copied the glplatform from
KWin which is known to work and more reliable than writing new custom
code even if it's a code copy. For master I'll look into splitting that
one out from KWin and putting it into a dedicated library so that we can
link it.

This of course means that the seccomp based sandbox is now incomplete
for NVIDIA users. An idea is to add an additional apparmor rule in
master to enforce the write restrictions in similar way without forcing
it for /dev.

Test Plan: I don't have an NVIDIA

Reviewers: #plasma

Subscribers: plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D7616

M  +1    -0    greeter/CMakeLists.txt
M  +1    -1    greeter/autotests/CMakeLists.txt
M  +4    -0    greeter/autotests/seccomp_test.cpp
A  +1062 -0    greeter/kwinglplatform.cpp     [License: GPL (v2)]
A  +416  -0    greeter/kwinglplatform.h     [License: GPL (v2)]
M  +22   -3    greeter/seccomp_filter.cpp

https://commits.kde.org/kscreenlocker/2136a38d88c8d0d7be67fe0c6c0870e53a6f7bc6
Comment 16 José Manuel Santamaría Lema 2017-08-31 17:36:03 UTC
[K]ubuntu packages to test the patch:
https://launchpad.net/~panfaust/+archive/ubuntu/kscreenlocker-nvidia
Comment 17 Christoph Feck 2017-09-17 23:22:14 UTC
*** Bug 383981 has been marked as a duplicate of this bug. ***
Comment 18 James Gilliland 2017-10-21 20:44:51 UTC
Have the same problem with an older nvidia driver(304) for a legacy card and this fixed it. Thanks.