Several essential KDE applications (sddm, krunner, plasmashell) segfault on startup with 361.16

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 ()

same here in arch

Nice driver changes, I better stick to 358 branch for a long time installed through these ppa on my ubuntu 16.04 LTS alpha gnome redaction [url]https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa[/url]

In any case these brand new driver has nothing new to users rather then bringing more troubles for packagers and distribution maintainers.

Vendor Neutral that the key word ;D

Thank you NVIDIA!

That’s why it’s called a Beta driver…

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.

Same on Fedora 22 x86_64, Qt 5.5.1, Plasma 5.5.1. Previous 358.16 works fine.

same here on latest openSUSE x86_64 Tumblewwed with KDE plasma 5.5.2.
reverted back to working 358.16.

any notice?

Same here with KDE Plasma 5.5.3 on arch

I also have this same problem on ChakraOS with plasma 5.5.x

Thanks for reporting this, everyone. I reproduced the problem and tracked it down to this buggy code in Qt5’s qxcbglxintegration.cpp:

static bool vendorChecked = false;
    static bool glxPbufferUsable = true;
    if (!vendorChecked) {
        vendorChecked = true;
        const char *glxvendor = glXGetClientString(glXGetCurrentDisplay(), GLX_VENDOR);
        if (glxvendor && !strcmp(glxvendor, "ATI"))
            glxPbufferUsable = false;
    }

When this code is called during sddm-greeter startup, there’s no current GLX context, so this gets called with a NULL argument. This got merged to upstream libglvnd here: GLX: Return dummy strings for glXGetClientString(NULL, ...) by aaronp24 · Pull Request #50 · NVIDIA/libglvnd · GitHub

I’ll integrate the fix into the copy of libglvnd that we ship for the next 361.* build.

@aplattner, then if build libglnvd by hand and overwrite the files, this working? or need rebuild your libraries

greetings

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.

then need use your branch instead of official branch?

greetings

EDIT: note of interest. i’m not use sddm, I start startx by hand

EDIT: not works for me if use your repo.

one question. need install the x11glvnd.so.0.0.0 (and symlinks) in /usr/lib/xorg/modules/extensions/?

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.

aplattner, so x11glvnd.so is libglx.so which is an xorg module? so why is it not named the same as the one that comes with the nvidia driver package?