Bug 358869 - Fix error source for a start failure
Summary: Fix error source for a start failure
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Unclassified
Component: general (show other bugs)
Version: 5.5.3
Platform: openSUSE RPMs Linux
: NOR crash
Target Milestone: 1.0
Assignee: David Edmundson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-01 12:50 UTC by Markus Elfring
Modified: 2016-03-02 10:33 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Function call trace for an abort of a program from the package "plasma5-workspace 5.5.3-2.1" (12.80 KB, text/plain)
2016-02-01 12:50 UTC, Markus Elfring
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Elfring 2016-02-01 12:50:40 UTC
Created attachment 96954 [details]
Function call trace for an abort of a program from the package "plasma5-workspace 5.5.3-2.1"

I am curious when I can use a KDE 5 desktop session again on my openSUSE Tumbleweed system without the attached start failure.
Comment 1 David Edmundson 2016-02-01 18:32:25 UTC
#10 0x00007f10496895c4 in QSGRenderLoop::handleContextCreationFailure(QQuickWindow*, bool) (this=this@entry=0x2e0ddc0, window=0x2c3ab50, isEs=isEs@entry=false) at /usr/src/debug/qtdeclarative-opensource-src-5.5.1/src/quick/scenegraph/qsgrenderloop.cpp:244

Your graphic drivers are missing

*** This bug has been marked as a duplicate of bug 345563 ***
Comment 2 Markus Elfring 2016-02-01 21:13:29 UTC
(In reply to David Edmundson from comment #1)
> Your graphic drivers are missing

It seems that this feedback does not really fit to my system configuration.
The graphic driver is provided by the script "NVIDIA-Linux-x86_64-352.79.run" here since a few days. The reported error message can still be reproduced if I reactivate the desired OpenGL/GLX support once more.
Comment 3 Markus Elfring 2016-02-02 10:05:22 UTC
(In reply to David Edmundson from comment #1)
> QSGRenderLoop::handleContextCreationFailure(QQuickWindow*, bool)

Can it be that OpenGL support can not be appropriately detected if anybody (like me) is trying a KDE desktop session out which should be displayed by the X server "Xephyr" from the software package "xorg-x11-server-extra 7.6_1.18.0-430.5"?
Comment 4 Marco Martin 2016-02-02 21:21:56 UTC
pasting inline

Thread 1 (Thread 0x7f104bb42900 (LWP 12537)):
[KCrash Handler]
#6  0x00007f1045033d38 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
#7  0x00007f104503518a in __GI_abort () at abort.c:78
#8  0x00007f10457bd82e in QMessageLogger::fatal(char const*, ...) const (context=..., message=<synthetic pointer>) at global/qlogging.cpp:1578
#9  0x00007f10457bd82e in QMessageLogger::fatal(char const*, ...) const (this=this@entry=0x7fff8890cbd0, msg=msg@entry=0x7f1049801d14 "%s") at global/qlogging.cpp:781
#10 0x00007f10496895c4 in QSGRenderLoop::handleContextCreationFailure(QQuickWindow*, bool) (this=this@entry=0x2e0ddc0, window=0x2c3ab50, isEs=isEs@entry=false) at /usr/src/debug/qtdeclarative-opensource-src-5.5.1/src/quick/scenegraph/qsgrenderloop.cpp:244
#11 0x00007f104968a545 in QSGGuiThreadRenderLoop::renderWindow(QQuickWindow*) (this=this@entry=0x2e0ddc0, window=0x2c3ab50) at /usr/src/debug/qtdeclarative-opensource-src-5.5.1/src/quick/scenegraph/qsgrenderloop.cpp:333
#12 0x00007f104968b44e in QSGGuiThreadRenderLoop::exposureChanged(QQuickWindow*) (this=0x2e0ddc0, window=0x2c3ab50) at /usr/src/debug/qtdeclarative-opensource-src-5.5.1/src/quick/scenegraph/qsgrenderloop.cpp:422
#13 0x00007f1045eecc3b in QWindow::event(QEvent*) (this=this@entry=0x2c3ab50, ev=ev@entry=0x7fff8890d080) at kernel/qwindow.cpp:2054
#14 0x00007f10496c2621 in QQuickWindow::event(QEvent*) (this=this@entry=0x2c3ab50, e=e@entry=0x7fff8890d080) at /usr/src/debug/qtdeclarative-opensource-src-5.5.1/src/quick/items/qquickwindow.cpp:1413
#15 0x00000000004422b6 in DesktopView::event(QEvent*) (this=0x2c3ab50, e=0x7fff8890d080) at /usr/src/debug/plasma-workspace-5.5.3/shell/desktopview.cpp:205
#16 0x00007f1046d178cc in QApplicationPrivate::notify_helper(QObject*, QEvent*) (this=this@entry=0x2718600, receiver=receiver@entry=0x2c3ab50, e=e@entry=0x7fff8890d080) at kernel/qapplication.cpp:3716
#17 0x00007f1046d1c9d6 in QApplication::notify(QObject*, QEvent*) (this=0x7fff8890d460, receiver=0x2c3ab50, e=0x7fff8890d080) at kernel/qapplication.cpp:3499
#18 0x00007f10459a0cf3 in QCoreApplication::notifyInternal(QObject*, QEvent*) (this=0x7fff8890d460, receiver=receiver@entry=0x2c3ab50, event=event@entry=0x7fff8890d080) at kernel/qcoreapplication.cpp:965
#19 0x00007f1045ee56e4 in QGuiApplicationPrivate::processExposeEvent(QWindowSystemInterfacePrivate::ExposeEvent*) (event=0x7fff8890d080, receiver=0x2c3ab50) at ../../src/corelib/kernel/qcoreapplication.h:227
#20 0x00007f1045ee56e4 in QGuiApplicationPrivate::processExposeEvent(QWindowSystemInterfacePrivate::ExposeEvent*) (e=0x2adc100) at kernel/qguiapplication.cpp:2648
#21 0x00007f1045ee637d in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) (e=e@entry=0x2adc100) at kernel/qguiapplication.cpp:1643
#22 0x00007f1045ecb9f8 in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) (flags=...) at kernel/qwindowsysteminterface.cpp:625
#23 0x00007f1035f92ed0 in userEventSourceDispatch(GSource*, GSourceFunc, gpointer) (source=<optimized out>) at eventdispatchers/qeventdispatcher_glib.cpp:70
#24 0x00007f10417d4097 in g_main_context_dispatch (context=0x7f102c001710) at gmain.c:3154
#25 0x00007f10417d4097 in g_main_context_dispatch (context=context@entry=0x7f102c001710) at gmain.c:3769
#26 0x00007f10417d42c8 in g_main_context_iterate (context=context@entry=0x7f102c001710, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840
#27 0x00007f10417d436c in g_main_context_iteration (context=0x7f102c001710, may_block=may_block@entry=1) at gmain.c:3901
#28 0x00007f10459f450f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (this=0x27bb260, flags=...) at kernel/qeventdispatcher_glib.cpp:418
#29 0x00007f104599e63a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (this=this@entry=0x7fff8890d310, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204
#30 0x00007f10459a62fd in QCoreApplication::exec() () at kernel/qcoreapplication.cpp:1229
#31 0x00007f1045edc53c in QGuiApplication::exec() () at kernel/qguiapplication.cpp:1527
#32 0x00007f1046d13f75 in QApplication::exec() () at kernel/qapplication.cpp:2976
#33 0x0000000000436527 in main(int, char**) (argc=4, argv=<optimized out>) at /usr/src/debug/plasma-workspace-5.5.3/shell/main.cpp:179
Comment 5 Kai Uwe Broulik 2016-02-02 21:23:24 UTC
I guess Xephyr doesn't support OpenGL?
Comment 6 Martin Klapetek 2016-02-03 19:36:51 UTC
Your OpenGL installation is possibly broken.

Can you verify glxgears works for you?
Comment 7 Markus Elfring 2016-02-04 08:29:24 UTC
(In reply to Martin Klapetek from comment #6)
> Your OpenGL installation is possibly broken.

A command like "glxinfo" gives me an other impression.


> Can you verify glxgears works for you?

Yes. - This graphic application is working as expected at the moment.
Comment 8 Markus Elfring 2016-02-04 10:56:25 UTC
(In reply to Martin Klapetek from comment #6)
> Your OpenGL installation is possibly broken.

Does the software situation look interesting if I try commands out like the following.

elfring@Sonne:~> Xephyr -screen 1280x980 -host-cursor :1 &
elfring@Sonne:~> DISPLAY=:1 dbus-launch /usr/bin/startkde &

> Can you verify glxgears works for you?

Xephyr KDE session:

elfring@Sonne:~> glxinfo
…
Xlib: extension "GLX" missing on display ":1".
Error: couldn't find RGB GLX visual or fbconfig
…
elfring@Sonne:~> glxgears
Xlib: extension "GLX" missing on display ":1".
Error: couldn't get an RGB, Double-buffered visual


Can a software like Mesa provide appropriate OpenGL support in such a simple test environment (while my regular desktop session display is performed by a proprietary graphic driver)?
Comment 9 Martin Klapetek 2016-02-04 13:29:37 UTC
It's not about mesa, it's about Xephyr that does not support
the GLX extension.

In other words, you cannot run Plasma in Xephyr.
Comment 10 Markus Elfring 2016-02-04 13:34:30 UTC
(In reply to Martin Klapetek from comment #9)
How are the chances to improve OpenGL usability also around the Ephyr X server?
Comment 11 Martin Klapetek 2016-02-04 13:36:13 UTC
Not by us. You'd have to request that with the X.org, sorry.
Comment 12 Markus Elfring 2016-02-04 13:37:57 UTC
(In reply to Martin Klapetek from comment #11)

How much are corresponding feature detection functions involved?
Comment 13 Martin Klapetek 2016-02-04 13:58:35 UTC
I'm not sure what you're asking...?
Comment 14 Markus Elfring 2016-02-04 14:03:04 UTC
(In reply to Martin Klapetek from comment #13)
Which functions are responsible for the determination of desired OpenGL support?

Can they provide a more user-friendly error message (instead of the attached software "crash" report)?
Comment 15 Martin Klapetek 2016-02-04 14:08:17 UTC
Ah. That detection is done in Qt. We actually try to handle this nicely
and show a nice message box telling you about your problem. Should
be in Plasma 5.5 onwards.

But I see you're running 5.5.3, correct?

https://quickgit.kde.org/?p=plasma-workspace.git&a=commit&h=727852897203fb750d9a06f04b78b07527573948
Comment 16 Markus Elfring 2016-02-04 14:15:38 UTC
(In reply to Martin Klapetek from comment #15)

Should the software "plasma workspace 5.5.4" work better for the discussed implementation details than the version I am using usually so far?
Comment 17 Martin Klapetek 2016-02-04 15:14:47 UTC
Updates are always a good thing to have. But it won't help
in this case.

We have however identified a possible improvement in the
error handling. Stay tuned.
Comment 18 Markus Elfring 2016-02-04 18:07:36 UTC
(In reply to Martin Klapetek from comment #17)

I am curious on how the next software improvement will look like.

How do you think about to collaborate also with an approach like the GL Vendor-Neutral Dispatch library?
https://github.com/NVIDIA/libglvnd
Comment 19 Martin Klapetek 2016-02-04 18:11:20 UTC
> I am curious on how the next software improvement will look like.

Pretty much like this:

connect(shell, &QQuickWindow::sceneGraphError, this, [=](QQuickWindow::SceneGraphError error, const QString & message) {
    QMessageBox::critical(0, "Cannot initialize OpenGL context", message);
    exit();
});

I just need to find the proper file to put this into.

> How do you think about to collaborate also with an approach like the GL Vendor-Neutral Dispatch library?

Sorry, we do UI stuff, we don't really do low-level GL.
Comment 20 Markus Elfring 2016-02-04 18:54:42 UTC
(In reply to Martin Klapetek from comment #19)

A better error message will help during the initialisation checks by the KDE software.

Another way is also to improve the selection of a desired OpenGL implementation for the configuration of a X server like "Ephyr".
Comment 21 David Edmundson 2016-03-02 10:33:12 UTC
Git commit e22989011f50456068bc5db21915bb7275f38a5a by David Edmundson.
Committed on 02/03/2016 at 10:32.
Pushed by davidedmundson into branch 'master'.

Fix showing openGL compatability warning to user

Make use of Qt5.5 API QQuickWindow::sceneGraphError rather than catching
the errors in a message filter.

I also merged with existing warning where contexts could be created, but
compiling shaders would not work.
REVIEW: 127254

M  +0    -22   shell/main.cpp
M  +8    -4    shell/shellcorona.cpp

http://commits.kde.org/plasma-workspace/e22989011f50456068bc5db21915bb7275f38a5a