Bug 364593 - Crash on logout after Nvidia driver update
Summary: Crash on logout after Nvidia driver update
Status: CLOSED DOWNSTREAM
Alias: None
Product: ksmserver
Classification: Plasma
Component: ui (show other bugs)
Version: 5.5.5
Platform: Kubuntu Linux
: HI crash
Target Milestone: ---
Assignee: phd
URL:
Keywords:
: 366325 379935 401447 408482 414446 418601 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-06-21 12:29 UTC by Lastique
Modified: 2023-05-14 07:33 UTC (History)
12 users (show)

See Also:
Latest Commit:
Version Fixed In: KDE Frameworks 5.78


Attachments
Crash log (7.48 KB, text/plain)
2016-06-21 12:30 UTC, Lastique
Details
Crash log (5.57 KB, text/plain)
2017-02-14 08:16 UTC, Aleksey Samoilov
Details
stacktrace (5.10 KB, text/plain)
2017-11-23 16:27 UTC, floux.dp
Details
Crash log on Kubuntu 17.10. (5.98 KB, text/plain)
2018-01-11 13:17 UTC, Lastique
Details
ksmserver crash log on Neon 5.13 (5.07 KB, text/plain)
2018-07-30 09:54 UTC, Alex Barrero
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lastique 2016-06-21 12:29:06 UTC
Whenever I update Nvidia drivers (as a package update, via Muon or apt-get), invoking the logout/reboot/shutdown dialog results in ksmserver crash. Often it is seen that the dialog is not drawn when the crash happens (i.e. the desktop fades out, according to the logout effect, but the panel with the logout/reboot/shutdown selection does not appear).

Reproducible: Always

Steps to Reproduce:
1. In KDE, update nvidia drivers to a different version. For example, you can switch from nvidia-364 to nvidia-367 package or back.
2. Invoke the logout/reboot/shutdown dialog. For example, by pressing the "Leave" button on the panel (the Lock/Logout widget).


Actual Results:  
ksmserver crashes, the logout dialog does not appear.

Expected Results:  
The crash should not happen.

Kubuntu 16.04 x86_64. Nvidia drivers 367.27.
Comment 1 Lastique 2016-06-21 12:30:08 UTC
Created attachment 99643 [details]
Crash log

Thread 1 (Thread 0x7f72a10ee900 (LWP 1970)):
[KCrash Handler]
#6  0x00007f72a0af2418 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#7  0x00007f72a0af401a in __GI_abort () at abort.c:89
#8  0x00007f729c3abff1 in qt_message_fatal (context=..., message=<synthetic pointer>) at global/qlogging.cpp:1578
#9  QMessageLogger::fatal (this=<optimized out>, msg=<optimized out>) at global/qlogging.cpp:781
#10 0x00007f729f426af1 in QSGRenderLoop::handleContextCreationFailure(QQuickWindow*, bool) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#11 0x00007f729f42f332 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#12 0x00007f729f42f733 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#13 0x00007f729c8ea2e5 in QWindow::event (this=0x1b5a710, ev=<optimized out>) at kernel/qwindow.cpp:2060
#14 0x00007f729f462871 in QQuickWindow::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#15 0x00007f729ce9205c in QApplicationPrivate::notify_helper (this=this@entry=0x1b15d00, receiver=receiver@entry=0x1b5a710, e=e@entry=0x7fff647898e0) at kernel/qapplication.cpp:3716
#16 0x00007f729ce97516 in QApplication::notify (this=0x1b17220, receiver=0x1b5a710, e=0x7fff647898e0) at kernel/qapplication.cpp:3499
#17 0x00007f729c59f62b in QCoreApplication::notifyInternal (this=0x1b17220, receiver=receiver@entry=0x1b5a710, event=event@entry=0x7fff647898e0) at kernel/qcoreapplication.cpp:965
#18 0x00007f729c8e24ec in QCoreApplication::sendSpontaneousEvent (event=0x7fff647898e0, receiver=0x1b5a710) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:227
#19 QGuiApplicationPrivate::processExposeEvent (e=0x2008ed0) at kernel/qguiapplication.cpp:2663
#20 0x00007f729c8e325d in QGuiApplicationPrivate::processWindowSystemEvent (e=e@entry=0x2008ed0) at kernel/qguiapplication.cpp:1658
#21 0x00007f729c8c6f38 in QWindowSystemInterface::sendWindowSystemEvents (flags=...) at kernel/qwindowsysteminterface.cpp:625
#22 0x00007f728e5dbf10 in userEventSourceDispatch (source=<optimized out>) at eventdispatchers/qeventdispatcher_glib.cpp:70
#23 0x00007f7296686127 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#24 0x00007f7296686380 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#25 0x00007f729668642c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#26 0x00007f729c5f5a7f in QEventDispatcherGlib::processEvents (this=0x1b67590, flags=...) at kernel/qeventdispatcher_glib.cpp:418
#27 0x00007f729c59cdea in QEventLoop::exec (this=this@entry=0x7fff64789bb0, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204
#28 0x00007f72a0ea25c9 in KSMShutdownDlg::exec (this=this@entry=0x1b5a710) at /build/plasma-workspace-kxRFE_/plasma-workspace-5.5.5.2/ksmserver/shutdowndlg.cpp:293
#29 0x00007f72a0ea2698 in KSMShutdownDlg::confirmShutdown (maysd=maysd@entry=true, choose=choose@entry=true, sdtype=@0x7fff64789cdc: KWorkSpace::ShutdownTypeReboot, bootOption=..., theme=...) at /build/plasma-workspace-kxRFE_/plasma-workspace-5.5.5.2/ksmserver/shutdowndlg.cpp:308
#30 0x00007f72a0eb1326 in KSMServer::shutdown (this=0x1ba2190, confirm=<optimized out>, sdtype=KWorkSpace::ShutdownTypeReboot, sdmode=KWorkSpace::ShutdownModeInteractive) at /build/plasma-workspace-kxRFE_/plasma-workspace-5.5.5.2/ksmserver/shutdown.cpp:164
#31 0x00007f72a0470ad9 in _SmsProcessMessage () from /usr/lib/x86_64-linux-gnu/libSM.so.6
#32 0x00007f72a0261071 in IceProcessMessages () from /usr/lib/x86_64-linux-gnu/libICE.so.6
#33 0x00007f72a0e9a012 in KSMServer::processData (this=0x1ba2190) at /build/plasma-workspace-kxRFE_/plasma-workspace-5.5.5.2/ksmserver/server.cpp:790
#34 0x00007f729c5cde4f in QtPrivate::QSlotObjectBase::call (a=0x7fff64789fe0, r=0x1ba2190, this=<optimized out>) at ../../include/QtCore/../../src/corelib/kernel/qobject_impl.h:124
#35 QMetaObject::activate (sender=sender@entry=0x1c44d80, signalOffset=<optimized out>, local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7fff64789fe0) at kernel/qobject.cpp:3698
Comment 2 Aleksey Samoilov 2017-02-14 08:16:19 UTC
Created attachment 104024 [details]
Crash log

Crash log related
Comment 3 Aleksey Samoilov 2017-02-14 08:17:08 UTC
Affected me in KDE Neon 5.9.1
Comment 4 Lastique 2017-02-14 09:18:53 UTC
I've found one workaround to this crash. You can invoke the logout/reboot/shutdown dialog once *before* the driver update, cancel it, then update the driver and then invoke the dialog again. ksmserver won't crash in that case.
Comment 5 floux.dp 2017-11-23 16:27:18 UTC
Created attachment 109024 [details]
stacktrace

Still occurs in KDE 5.8.7

OS : openSUSE Leap 42.3
Qt : 5.6.2
Kernel : 4.4.92-31-default x86_64
Comment 6 Lastique 2018-01-11 13:17:13 UTC
Created attachment 109792 [details]
Crash log on Kubuntu 17.10.

Still crashes on Kubuntu 17.10. Plasma 5.10.5.
Comment 7 Christoph Feck 2018-03-30 19:36:03 UTC
If you are updating nvidia drivers, you must reboot your system. This is because every driver version comes with its own kernel module.

If the driver cannot find the matching kernel module, Qt is not able to create OpenGL contexts, despite the driver announcing that it supports OpenGL.
Comment 8 Lastique 2018-03-30 22:11:51 UTC
I understand the source of the problem - the updated OpenGL part of the driver may not be binary compatible with the loaded kernel module or X11 driver or something and therefore refuses to load. But "reboot after updating the driver" is not a resolution because *I cannot reboot* except by killing X server. This bug requests a better solution than killing X server. For example, cache OpenGL context on boot or draw the logout/reboot UI in software.
Comment 9 Christoph Feck 2018-04-05 11:47:52 UTC
It still needs to be fixed in the NVIDIA driver. Plasma works completely fine on my system without OpenGL support, because Qt has a software fallback renderer, see http://blog.qt.io/blog/2015/01/22/introducing-the-qt-quick-2d-renderer/

As I wrote in comment #7, the issue is that NVIDIA says it does support OpenGL _before_ checking if there is kernel version mismatch.
Comment 10 Lastique 2018-04-05 14:53:04 UTC
I've created this thread:

https://devtalk.nvidia.com/default/topic/1031836/linux/opengl-context-cannot-be-created-after-nvidia-driver-update-cannot-reboot-the-system/

Please, feel free to add any technical details.

I still think this is a bug in KDE as well, even if the driver behaves not as you'd expect. A crash is always a bug in the application.

I will reopen this bug if I get the response from Nvidia indicating that the fix should be done in the application.
Comment 11 Christoph Feck 2018-04-05 14:56:03 UTC
It is not a crash. Qt simply aborts if an OpenGL driver fails to create an OpenGL context. You can report this to Qt developers, but they will tell you it is a driver bug. An OpenGL driver that doesn't allow to access the OpenGL API is simply broken.
Comment 12 Lastique 2018-04-06 20:02:23 UTC
I've created a Qt bug: https://bugreports.qt.io/browse/QTBUG-67535
Comment 13 Alex Barrero 2018-07-30 09:54:10 UTC
Created attachment 114216 [details]
ksmserver crash log on Neon 5.13

Still affected in KDE Neon 5.13

Qt: 5.11.1
Kernel: 4.15.0-29-generic
Comment 14 Alex Barrero 2018-10-16 18:10:15 UTC
anything new about this issue? update after update is always happening this. Is it so difficult to find a solution?

KDE Neon 5.14
Nvidia Driver 410.57
Comment 15 Christoph Feck 2018-12-20 16:06:05 UTC
*** Bug 401447 has been marked as a duplicate of this bug. ***
Comment 16 Christoph Feck 2018-12-20 16:11:23 UTC
*** Bug 366325 has been marked as a duplicate of this bug. ***
Comment 17 Christoph Feck 2018-12-20 16:11:50 UTC
*** Bug 379935 has been marked as a duplicate of this bug. ***
Comment 18 Christoph Feck 2019-06-25 15:11:54 UTC
*** Bug 408482 has been marked as a duplicate of this bug. ***
Comment 19 Christoph Feck 2019-12-19 16:17:20 UTC
*** Bug 414446 has been marked as a duplicate of this bug. ***
Comment 20 Liam Dawe 2020-03-14 17:30:47 UTC
Not sure why this was set as resolved, it's clearly not. I would also like to track this, as it's such a crazy issue to have. Forcing people to use terminal to shut down, after updating NVIDIA is not going to win us over an users.

Something really needs to be done about this.
Comment 21 Christoph Feck 2020-03-15 03:00:13 UTC
It was marked as resolved, because there is no more work to be done by KDE developers. The fix needs to be made in the NVIDIA drivers, or a workaround added in QtQuick to detect a broken OpenGL driver and fall back to software rendering.
Comment 22 Christoph Feck 2020-04-06 12:39:29 UTC
*** Bug 418601 has been marked as a duplicate of this bug. ***
Comment 23 Arthur Huillet 2020-05-05 09:54:48 UTC
I am not sure what is being referred to as "the driver announcing that it supports OpenGL". I assume this is from interpreting the values of some glGetString queries.
Note that GL context creation can legally fail for various reasons, regardless of what glGetString returns. It not valid to assume that because glGetString returns anything specific, then context creation will or must not fail.
The application therefore ought to handle the context creation error gracefully, and it seems invalid - at least with the evidence on this thread - to call that a NVIDIA driver bug.
It is certainly less than optimal behavior that the context creation fails, but that is not a bug, and, unfortunately, unlikely to change in the near future.
Comment 24 phd 2021-08-01 22:23:43 UTC
Fixed in KDE Frameworks 5.78.
See bug #366156
Comment 25 Johannes Claesson 2022-05-22 13:15:55 UTC
Why is this marked as fixed? Still an issue as of 5.24.90
Comment 26 phd 2023-05-14 07:02:08 UTC
@Johannes Claesson
I have noticed ksmserver crashing again recently after nvidia drivers update.

What is more, trying to run drkonqi for that crash makes drkonqi crash as well.
This implies there might be a different reason for those crashes than the one originally solved for this bug report.
But I need to reproduce it and actually get the backtrace to confirm it.

I think:
1. we should have a default shortcut assigned to "Logout without confirmation" action: Ctrl+Alt+Shift+Del
2. DrKonqi probably should not use QtQuick, because user is left with a crash handler that itself crashes in such situations...
It's a pity that QtQuick can't handle fallback to software rendering by itself when it cannot initialize OpenGL context internally.