After installing 361.16, several essential KDE applications fail to start with a segfault. This manifests immediately as a black screen when sddm attempts to start. Attempting to start a KDE session using “startx” results in both plasmashell and krunner failing to start, yielding an unusable desktop. This didn’t happen with the 358 series.
I have attached both the nvidia-bug-report log and the stacktrace produced by plasmashell crashing. The stacktraces for all the crashing applications report the crash being in the same function call (0x00007fe7623640da in glXGetClientString () from /usr/lib/nvidia-361/libGLX.so.0). nvidia-bug-report.log.gz (82.8 KB) plasmashell-20160105-205100.kcrash.txt (7.04 KB)
Same issue here, but the stack trace ends in XScreenCount to be precise.
Thread 1 (Thread 0x7f572f17b8c0 (LWP 13745)):
[KCrash Handler]
#6 0x00007f572d813c40 in XScreenCount () at /usr/lib64/libX11.so.6
#7 0x00007f571feec0da in glXGetClientString () at /usr/lib64/libGLX.so.0
#8 0x00007f57186020d3 in () at /usr/lib64/qt5/plugins/xcbglintegrations/libqxcb-glx-integration.so
#9 0x00007f5718602281 in () at /usr/lib64/qt5/plugins/xcbglintegrations/libqxcb-glx-integration.so
#10 0x00007f572cca16bb in QSGRenderLoop::instance() () at /usr/lib64/libQt5Quick.so.5
#11 0x00007f572ccd1475 in QQuickWindowPrivate::init(QQuickWindow*, QQuickRenderControl*) () at /usr/lib64/libQt5Quick.so.5
#12 0x00007f572eb864ee in PlasmaQuick::Dialog::Dialog(QQuickItem*) () at /usr/lib64/libKF5PlasmaQuick.so.5
#13 0x00007f5710de7340 in () at /usr/lib64/qt5/qml/org/kde/plasma/core/libcorebindingsplugin.so
#14 0x00007f572c04edfb in QQmlType::create() const () at /usr/lib64/libQt5Qml.so.5
#15 0x00007f572c0ac6b4 in () at /usr/lib64/libQt5Qml.so.5
#16 0x00007f572c0ad13f in () at /usr/lib64/libQt5Qml.so.5
#17 0x00007f572c03c287 in () at /usr/lib64/libQt5Qml.so.5
#18 0x00007f572c03cadc in QQmlIncubationController::incubateFor(int) () at /usr/lib64/libQt5Qml.so.5
#19 0x00007f572d10abac in () at /usr/lib64/libKF5Declarative.so.5
#20 0x00007f572c03c949 in QQmlEnginePrivate::incubate(QQmlIncubator&, QQmlContextData*) () at /usr/lib64/libQt5Qml.so.5
#21 0x00007f572c0382ec in QQmlComponent::create(QQmlIncubator&, QQmlContext*, QQmlContext*) () at /usr/lib64/libQt5Qml.so.5
#22 0x00007f572d107a65 in KDeclarative::QmlObject::completeInitialization(QHash<QString, QVariant> const&) () at /usr/lib64/libKF5Declarative.so.5
#23 0x00007f572d107b0c in () at /usr/lib64/libKF5Declarative.so.5
#24 0x00007f572d107ca9 in () at /usr/lib64/libKF5Declarative.so.5
#25 0x00000000004668bb in Osd::Osd(ShellCorona*) ()
#26 0x0000000000459d82 in ShellCorona::ShellCorona(QObject*) ()
#27 0x0000000000462fc9 in ShellManager::loadHandlers() ()
#28 0x00007f5728fe9d79 in QObject::event(QEvent*) () at /usr/lib64/libQt5Core.so.5
#29 0x00007f572a3328cc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5
#30 0x00007f572a3379d6 in QApplication::notify(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5
#31 0x00007f5728fbbcf3 in QCoreApplication::notifyInternal(QObject*, QEvent*) () at /usr/lib64/libQt5Core.so.5
#32 0x00007f5728fbe016 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /usr/lib64/libQt5Core.so.5
#33 0x00007f572900f103 in () at /usr/lib64/libQt5Core.so.5
#34 0x00007f5724dee097 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0
#35 0x00007f5724dee2c8 in () at /usr/lib64/libglib-2.0.so.0
#36 0x00007f5724dee36c in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0
#37 0x00007f572900f50f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5
#38 0x00007f5728fb963a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5
#39 0x00007f5728fc12fd in QCoreApplication::exec() () at /usr/lib64/libQt5Core.so.5
#40 0x0000000000436571 in main ()
It actually wasn’t that big a deal at all from a packaging point of view. Just a couple of libraries changed names and a new library was added. The KDE crashing is an actual bug in the driver; it is unrelated to the packaging.
libGLX_indirect.so.0, libGLX.so.0, libGLX_nvidia.so.361.16, libGLESv1_CM_nvidia.so.361.16, libGLESv2_nvidia.so.361.16, libnvidia-ptxjitcompiler.so.361.16 and libnvidia-fatbinaryloader.so.361.16 were all new libraries, but I don’t think that was the point he was making.
Correct, sorry. I was only thinking about the changes I had to make for the Ubuntu package and not all the new libraries. The packaging script for Ubuntu already grabs libnv*.so*, so that covered most of the new ones.
Yes, I verified that that works with my specific commit da090a2e381982d770a56f0018bc95a4a2604126. I think the master branch contains some ABI changes vs. the libraries shipped with 361.16, so it didn’t work when I tried it. Kyle is still nailing down the official ABI so please don’t rely on being able to mix and match version of the NVIDIA driver with different versions of libglvnd just yet.
seem the x11glvnd.so is libglx** that comes with the nvidia drivers, on most distros they like to put it in different places, in gentoo its in /usr/lib64/opengl/nvidia/extensions/ so x11glvnd.so would probably go in there, but also I don’t know if the x11* one is pure x11 or if its the same as the libglx*.so in the nvidia driver package.
aplattner - please hurry with the fix, and thank you.
No, the fix here is for libGLX.so.0, which is the new home for the glX* client functions. You’re thinking of libglx.so (note lowercase) which is the server-side implementation of the X11 GLX extension.
In the new ABI model, libGL.so.1 is a filter library that wraps the new libGLX.so.0 and libOpenGL.so.0 libraries. So when Qt5 calls glXGetClientString, it’s really calling the one from libGLX.so.0.