Bug 350853 - multiple successive plasmashell and krunner crashes even though OpenGL drivers are installed on rv200 if "Enable compositor on startup" is enabled
Summary: multiple successive plasmashell and krunner crashes even though OpenGL driver...
Status: RESOLVED DOWNSTREAM
Alias: None
Product: plasmashell
Classification: Plasma
Component: general (show other bugs)
Version: 5.3.2
Platform: Fedora RPMs Linux
: NOR crash
Target Milestone: 1.0
Assignee: David Edmundson
URL:
Keywords: drkonqi
Depends on:
Blocks:
 
Reported: 2015-08-01 08:28 UTC by Felix Miata
Modified: 2015-08-24 08:21 UTC (History)
6 users (show)

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


Attachments
glxgears output (17.42 KB, text/plain)
2015-08-01 09:22 UTC, Felix Miata
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Miata 2015-08-01 08:28:23 UTC
Application: plasmashell (5.3.2)

Qt Version: 5.4.2
Operating System: Linux 4.1.2-200.fc22.i686+PAE i686
Distribution (Platform): Fedora RPMs

-- Information about the crash:
Trying to get Plasma5 session to start after installing mesa-dri-drivers (OpenGL) rpm.

The crash can be reproduced every time.

-- Backtrace:
Application: Plasma (plasmashell), signal: Aborted
Using host libthread_db library "/lib/libthread_db.so.1".
[Current thread is 1 (Thread 0xb19f0800 (LWP 3037))]

Thread 3 (Thread 0xb1612b40 (LWP 3039)):
#0  0xb770ebe8 in __kernel_vsyscall ()
#1  0xb4b700db in poll () from /lib/libc.so.6
#2  0xb7127718 in _xcb_conn_wait () from /lib/libxcb.so.1
#3  0xb71298d4 in xcb_wait_for_event () from /lib/libxcb.so.1
#4  0xb175179b in QXcbEventReader::run() () from /usr/lib/qt5/plugins/platforms/libqxcb.so
#5  0xb4ec2290 in QThreadPrivate::start(void*) () from /lib/libQt5Core.so.5
#6  0xb47fd370 in start_thread () from /lib/libpthread.so.0
#7  0xb4b7d2be in clone () from /lib/libc.so.6

Thread 2 (Thread 0xb0002b40 (LWP 3041)):
#0  0xb4b6a2cf in read () from /lib/libc.so.6
#1  0xb41418e6 in g_wakeup_acknowledge () from /lib/libglib-2.0.so.0
#2  0xb40f7b3a in g_main_context_check () from /lib/libglib-2.0.so.0
#3  0xb40f8042 in g_main_context_iterate.isra () from /lib/libglib-2.0.so.0
#4  0xb40f81f7 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#5  0xb510c71f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/libQt5Core.so.5
#6  0xb50a9347 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/libQt5Core.so.5
#7  0xb50a97c4 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/libQt5Core.so.5
#8  0xb4ebc5dc in QThread::exec() () from /lib/libQt5Core.so.5
#9  0xb69a76f0 in QQmlThreadPrivate::run() () from /lib/sse2/libQt5Qml.so.5
#10 0xb4ec2290 in QThreadPrivate::start(void*) () from /lib/libQt5Core.so.5
#11 0xb47fd370 in start_thread () from /lib/libpthread.so.0
#12 0xb4b7d2be in clone () from /lib/libc.so.6

Thread 1 (Thread 0xb19f0800 (LWP 3037)):
[KCrash Handler]
#6  0xb770ebe8 in __kernel_vsyscall ()
#7  0xb4ab2796 in raise () from /lib/libc.so.6
#8  0xb4ab4027 in abort () from /lib/libc.so.6
#9  0xb4ead9bc in QMessageLogger::fatal(char const*, ...) const () from /lib/libQt5Core.so.5
#10 0xb178554d in QGLXContext::init(QXcbScreen*, QPlatformOpenGLContext*) () from /usr/lib/qt5/plugins/platforms/libqxcb.so
#11 0xb1755d2b in QXcbIntegration::createPlatformOpenGLContext(QOpenGLContext*) const () from /usr/lib/qt5/plugins/platforms/libqxcb.so
#12 0xb53ea24e in QOpenGLContext::create() () from /lib/libQt5Gui.so.5
#13 0xb17859b9 in QGLXContext::queryDummyContext() () from /usr/lib/qt5/plugins/platforms/libqxcb.so
#14 0xb1785b9e in QGLXContext::supportsThreading() () from /usr/lib/qt5/plugins/platforms/libqxcb.so
#15 0xb17563fd in QXcbIntegration::hasCapability(QPlatformIntegration::Capability) const () from /usr/lib/qt5/plugins/platforms/libqxcb.so
#16 0xb6c5fd8f in QSGRenderLoop::instance() () from /lib/libQt5Quick.so.5
#17 0xb6c96bad in QQuickWindowPrivate::init(QQuickWindow*, QQuickRenderControl*) () from /lib/libQt5Quick.so.5
#18 0xb6c96d5c in QQuickWindow::QQuickWindow(QWindow*) () from /lib/libQt5Quick.so.5
#19 0xb76b6535 in PlasmaQuick::Dialog::Dialog(QQuickItem*) () from /lib/libKF5PlasmaQuick.so.5
#20 0xaee149a9 in void QQmlPrivate::createInto<PlasmaQuick::Dialog>(void*) () from /usr/lib/qt5/qml/org/kde/plasma/core/libcorebindingsplugin.so
#21 0xb6931eda in QQmlType::create() const () from /lib/sse2/libQt5Qml.so.5
#22 0xb69a2b4a in QQmlObjectCreator::createInstance(int, QObject*, bool) () from /lib/sse2/libQt5Qml.so.5
#23 0xb69a345a in QQmlObjectCreator::create(int, QObject*, QQmlInstantiationInterrupt*) () from /lib/sse2/libQt5Qml.so.5
#24 0xb691dfd2 in QQmlIncubatorPrivate::incubate(QQmlInstantiationInterrupt&) () from /lib/sse2/libQt5Qml.so.5
#25 0xb691e861 in QQmlIncubationController::incubateFor(int) () from /lib/sse2/libQt5Qml.so.5
#26 0xb6f1706d in KDeclarative::QmlObjectIncubationController::incubatingObjectCountChanged(int) () from /lib/libKF5Declarative.so.5
#27 0xb691e657 in QQmlEnginePrivate::incubate(QQmlIncubator&, QQmlContextData*) () from /lib/sse2/libQt5Qml.so.5
#28 0xb69199df in QQmlComponent::create(QQmlIncubator&, QQmlContext*, QQmlContext*) () from /lib/sse2/libQt5Qml.so.5
#29 0xb6f04258 in KDeclarative::QmlObject::completeInitialization(QHash<QString, QVariant> const&) () from /lib/libKF5Declarative.so.5
#30 0xb6f0440d in KDeclarative::QmlObjectPrivate::scheduleExecutionEnd() () from /lib/libKF5Declarative.so.5
#31 0xb6f04608 in KDeclarative::QmlObjectPrivate::execute(QUrl const&) [clone .part.26] [clone .constprop.32] () from /lib/libKF5Declarative.so.5
#32 0x080abe95 in Osd::Osd (this=0x93d9910, corona=0x93c8e68) at ../../shell/osd.cpp:42
#33 0x0809c7c6 in ShellCorona::ShellCorona (this=0x93c8e68, parent=0x9399778) at ../../shell/shellcorona.cpp:176
#34 0x080a6fac in ShellManager::loadHandlers (this=this@entry=0x9399778) at ../../shell/shellmanager.cpp:101
#35 0x080ceb9c in ShellManager::qt_static_metacall (_o=0x9399778, _c=QMetaObject::InvokeMetaMethod, _id=5, _a=0x938a698) at moc_shellmanager.cpp:100
#36 0xb50de60b in QMetaCallEvent::placeMetaCall(QObject*) () from /lib/libQt5Core.so.5
#37 0xb50e26a9 in QObject::event(QEvent*) () from /lib/libQt5Core.so.5
#38 0xb59c4604 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib/libQt5Widgets.so.5
#39 0xb59ca3c2 in QApplication::notify(QObject*, QEvent*) () from /lib/libQt5Widgets.so.5
#40 0xb50ac795 in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /lib/libQt5Core.so.5
#41 0xb50aed41 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /lib/libQt5Core.so.5
#42 0xb50af374 in QCoreApplication::sendPostedEvents(QObject*, int) () from /lib/libQt5Core.so.5
#43 0xb510c23f in postEventSourceDispatch(_GSource*, int (*)(void*), void*) () from /lib/libQt5Core.so.5
#44 0xb40f7d43 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#45 0xb40f8125 in g_main_context_iterate.isra () from /lib/libglib-2.0.so.0
#46 0xb40f81f7 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#47 0xb510c700 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/libQt5Core.so.5
#48 0xb17871c7 in QPAEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/qt5/plugins/platforms/libqxcb.so
#49 0xb50a9347 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/libQt5Core.so.5
#50 0xb50a97c4 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /lib/libQt5Core.so.5
#51 0xb50b227a in QCoreApplication::exec() () from /lib/libQt5Core.so.5
#52 0xb53a0565 in QGuiApplication::exec() () from /lib/libQt5Gui.so.5
#53 0xb59c0125 in QApplication::exec() () from /lib/libQt5Widgets.so.5
#54 0x0806f2eb in main (argc=4, argv=0xbfc50244) at ../../shell/main.cpp:154

Possible duplicates by query: bug 350852, bug 350820, bug 350666, bug 350127, bug 350009.

Reported using DrKonqi
Comment 1 David Edmundson 2015-08-01 08:29:10 UTC

*** This bug has been marked as a duplicate of bug 350852 ***
Comment 2 Bhushan Shah 2015-08-01 08:34:23 UTC
Both are same bug.

*** This bug has been marked as a duplicate of bug 350852 ***
Comment 3 David Edmundson 2015-08-01 08:37:30 UTC
If you want to reopen this, can you run glxinfo and paste results.
Comment 4 Felix Miata 2015-08-01 09:22:03 UTC
Created attachment 93829 [details]
glxgears output

Downstream bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1249280
Comment 5 David Edmundson 2015-08-01 09:24:05 UTC
OK. 

We use OpenGL 2, which I can't see there.

What hardware are you running?
Comment 6 David Edmundson 2015-08-01 09:24:37 UTC
Edit, just seen in the downstream bug report.

rv200
Comment 7 Felix Miata 2015-08-01 09:36:45 UTC
I got a plasma5 session to start without crashing after opening systemsettings5 in an IceWM session and deselecting "Enable compositor on startup".
Comment 8 David Edmundson 2015-08-01 09:38:01 UTC
and then the shell with the panels and such worked?
Comment 9 Felix Miata 2015-08-01 09:55:55 UTC
In plasma session:
Configurable panel works.
Application menu works.
Systemsettings5 works.
Konsole works.
Ksnapshot works.
KCalc works.
Kcmshell5 xserver works.
Konq works.
Firefox 39 and esr17 both work.
Comment 10 David Edmundson 2015-08-01 10:06:08 UTC
I don't understand.  Plasmashell (the panels) shouldn't be working.

The errors you got were in that application when it used OpenGL. Changing the window manager compositing shouldn't make any difference to that application.

CC'ing one of the Window manager people for comments.
Comment 11 Kevin Kofler 2015-08-01 11:29:05 UTC
Plasmashell normally works in Fedora (by using llvmpipe), thanks to this hack:
http://pkgs.fedoraproject.org/cgit/qt5-qtbase.git/tree/10-qt5-check-opengl2.sh
The thing is that the other stuff should also be working. We can discuss this in the downstream bug tracker, because the script was unfortunately not added to upstream Qt, only the flag it uses was.
Comment 12 Kevin Kofler 2015-08-01 11:36:58 UTC
Followup: https://bugzilla.redhat.com/show_bug.cgi?id=1249280#c1
Comment 13 Kevin Kofler 2015-08-01 11:44:05 UTC
PS: See also https://codereview.qt-project.org/#/c/76992/ for the other half of the hack.
Comment 14 Kevin Kofler 2015-08-01 12:33:02 UTC
KWin 5 should be using XRender compositing on this hardware, by the way.
Comment 15 Felix Miata 2015-08-01 17:06:22 UTC
Is it possible that bug 317929 plays a role in this? I have 'Option "Composite" "Disable"' set in X config, yet it's been necessary also to set autoload=false for Module-kscreen to have it or xrandr startup commands obeyed.
Comment 16 Kevin Kofler 2015-08-02 12:51:25 UTC
Disabling Composite in xorg.conf is a bad idea. It's no wonder that KWin compositing does not work if you have the Composite extension disabled.

I also still don't know:
* whether the plasmashell crash is gone for good now nor
* why you had it on Fedora to begin with (Did you install mesa-dri-drivers within a running session? The xinit script only runs on X11 startup, so QT_XCB_FORCE_SOFTWARE_OPENGL gets set at that time. I did it this way because spawning glxinfo is a relatively expensive operation.) nor
* why you had to install mesa-dri-drivers to begin with (it's installed by default on all our spins, isn't it?) nor
* what other strange things (other than not having mesa-dri-drivers installed and disabling the Composite extension) you did to your Fedora installation.

Can you reproduce any of the crashes on the unmodified Fedora KDE Live image?
Comment 17 Felix Miata 2015-08-03 03:55:03 UTC
(In reply to Kevin Kofler from comment #16)
> Disabling Composite in xorg.conf is a bad idea. It's no wonder that KWin
> compositing does not work if you have the Composite extension disabled.

I've had no luck finding any doc that reports Xorg enabled compositing is prerequisite to basic functionality using any version of Plasma.
 
> I also still don't know:
> * whether the plasmashell crash is gone for good now nor

I think installing mesa-dri-drivers has made that crashing historical.

> * why you had it on Fedora to begin with

If you mean disabling compositing, years ago, some dev(s) invented new ways to annoy. As these new annoyances depended on compositing, once I discovered disabling compositing made the annoyances go away, I made a routine of disabling compositing, and as a bonus, found X to be faster so configured.

I have well over two dozen Fedora installations 21 or newer. Their collective purpose is, as with other distros, testing what devs don't test, older, real hardware, rather than VMs running on fast recent hardware. Disabling compositing is routine post-installation activity here regardless of distro or hardware. If I don't do it, how will anyone find out before it's too late to fix when some evolutionary development has an unintended and unknown side effect of making compositing a requirement?

> (Did you install mesa-dri-drivers
> within a running session? The xinit script only runs on X11 startup, so

IIRC, it's been years since I installed any Fedora package while X was running. :-)

> * nor why you had to install mesa-dri-drivers to begin with (it's installed by
> default on all our spins, isn't it?) nor

Apparently it does not get installed automatically, at least if original install is minimal X and only as few packages as necessary (according to the package management system) are installed to get a working Xorg and KDE session.

> * what other strange things (other than not having mesa-dri-drivers
> installed and disabling the Composite extension) you did to your Fedora
> installation.

Those I can think of (that could conceivably have any impact on Xorg or KDE):

        Option "XkbOptions" "terminate:ctrl_alt_bksp"
	Option	"DPMS"	"off"
	DisplaySize ...
	PreferredMode...
	Virtual... (not used on comment 0 host)

	Xft.dpi is null

	# kdedrc
		[Module-kscreen]
		autoload=false

	Booting more often to multi-user.target than graphical.target, usually to run startx
	No Plymouth
	Droid tops all three preferred fonts lists in fontconfig.
	Kernel cmdline usually includes video=1024x768@60 (Grub2 is not installed)

> Can you reproduce any of the crashes on the unmodified Fedora KDE Live image?

Except for Knoppix, which I boot maybe 2-3 sessions per year, I don't download or boot from burned .iso images. I most often install to HD via HTTP started from Grub loading installation kernel and initrd, rarely from booting installation media, never via pxe, always manually, like a non-developer user might, not making use of installation scripting like Kickstart.
Comment 18 Kevin Kofler 2015-08-03 10:40:51 UTC
The Plasmashell crashes were due to mesa-dri-drivers not being installed: In Fedora, even the llvmpipe is in mesa-dri-drivers. If you don't have mesa-dri-drivers, you have NO OpenGL support at all. No wonder QML2 doesn't work then.

Please open a separate bug for the KWin / Composite issues, as they have nothing to do with the plasmashell backtrace this bug is about.
Comment 19 Kevin Kofler 2015-08-03 11:05:16 UTC
I'm resolving this bug as DOWNSTREAM (missing package-level dependency). As I wrote above, the KWin issues are unrelated and need a separate bug report.

By the way:
> Except for Knoppix, which I boot maybe 2-3 sessions per year, I don't download or
> boot from burned .iso images. I most often install to HD via HTTP started from Grub
> loading installation kernel and initrd, rarely from booting installation media, never
> via pxe, always manually, like a non-developer user might, not making use of
> installation scripting like Kickstart.

1. Especially BECAUSE you have hardware that many developers don't have, you should be more responsive to requests for testing. (But in this case, I happen to also have a Radeon 9200 SE and can and will test it myself. That doesn't mean testing the live image on your machines wouldn't also be useful, because your hardware is almost certainly not identical to mine. And by the way, the Radeon 9200 SE is my primary machine, so it's not true all the devs use brand new hardware. :-) But this is also why I haven't done the testing yet, I need to reboot my primary machine for that, after burning a live DVD because I don't have any current 32-bit ones lying around.)
2. The live image is the most effective way to test a known-good Fedora setup, without affecting any of the installations present on the machine. Burn (or put on a USB stick, if your machine supports booting from USB), boot and see what happens. I didn't ask you to install from it, just to test ON the live image.
3. Because of your unusual setup, it is important to know for debugging whether this also happens on a known-good default setup. This is why I asked you to test the live image.
4. A non-developer user should not, and hopefully will usually not, install from netinstall with "minimal X". We recommend all our users to always install from the live image. So you are in fact NOT testing what normal users will get.
5. If you report bugs from heavily-customized Fedora installations, please indicate so from day 1. Not knowing this wasted a lot of our time debugging the issue. (Now I'll try to remember your name, so next time you report a bug, I'll hopefully know "Ah, this is the freak with the minimal netinstall who disables Composite and uses startx.", but you should not expect everyone to know you that way.) Old hardware does not necessarily imply the other changes you did. I installed from the live image (several releases ago though, upgraded using yum), I had mesa-dri-drivers installed out of the box, and I don't have Composite disabled (but admittedly, I disable compositing at KWin level because I don't like the effects).
Comment 20 Felix Miata 2015-08-03 21:26:47 UTC
(In reply to Kevin Kofler from comment #18)
> Please open a separate bug for the KWin / Composite issues, as they have
> nothing to do with the plasmashell backtrace this bug is about.

Is not that bug 346059, maybe in need of change from plasmashell to kwin?
Comment 21 Kevin Kofler 2015-08-04 02:25:58 UTC
Probably, yes. So let's use bug #346059, unless we find out that both plasmashell and KWin need fixing for that case (Composite disabled), then we need 2 bugs.