Bug 352548 - kwin_x11 crashes switching from GLX to EGL
Summary: kwin_x11 crashes switching from GLX to EGL
Status: RESOLVED INTENTIONAL
Alias: None
Product: kwin
Classification: Plasma
Component: glx (show other bugs)
Version: 5.4.0
Platform: Compiled Sources Linux
: NOR crash
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: drkonqi
Depends on:
Blocks:
 
Reported: 2015-09-11 09:21 UTC by A. Wilcox (awilfox)
Modified: 2017-07-02 15:12 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
glxinfo -l output (26.86 KB, text/plain)
2015-09-12 16:09 UTC, A. Wilcox (awilfox)
Details
New crash information added by Dr awilfox, filling in for DrKonqi (40.98 KB, text/plain)
2015-09-16 15:05 UTC, A. Wilcox (awilfox)
Details
KWin supportInformation (4.73 KB, text/plain)
2015-11-07 08:15 UTC, A. Wilcox (awilfox)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description A. Wilcox (awilfox) 2015-09-11 09:21:38 UTC
Application: kwin_x11 (5.4.0)
 (Compiled from sources)
Qt Version: 5.4.2
Operating System: Linux 4.1.0-rc8-pwyll x86_64
Distribution: "Gentoo Base System release 2.2"

-- Information about the crash:
- What I was doing when the application crashed:
I had just clicked "Apply" to switch OpenGL backend from GLX to EGL.  GLX has been causing a number of issues on my computer (which it did not in KWin 4...) so I decided to switch to EGL.  Couldn't even switch out without it giving one last crash - but so far EGL backend has been stable, so at least I was able to switch at all.

- Unusual behavior I noticed:
Under GLX, window borders were glitching and flickering and showing odd rainbow patterns when I held Alt+Tab.

The crash can be reproduced sometimes.

-- Backtrace:
Application: KWin (kwin_x11), signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f763bd2b800 (LWP 23904))]

Thread 3 (Thread 0x7f761c1eb700 (LWP 23920)):
#0  0x00007f76491bfbc3 in select () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007f7647f9a23b in qt_safe_select (nfds=18, fdread=0x7f7614000a78, fdwrite=0x7f7614000d08, fdexcept=0x7f7614000f98, orig_timeout=0x0) at kernel/qcore_unix.cpp:75
#2  0x00007f7647f9bbc2 in QEventDispatcherUNIXPrivate::doSelect (this=this@entry=0x7f76140008e0, flags=..., flags@entry=..., timeout=0x0) at kernel/qeventdispatcher_unix.cpp:196
#3  0x00007f7647f9c05b in QEventDispatcherUNIX::processEvents (this=0x7f76140008c0, flags=...) at kernel/qeventdispatcher_unix.cpp:607
#4  0x00007f7647f427eb in QEventLoop::exec (this=this@entry=0x7f761c1ead50, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204
#5  0x00007f7647d5863a in QThread::exec (this=this@entry=0x2e92a60) at thread/qthread.cpp:503
#6  0x00007f76440339b8 in QQmlThreadPrivate::run (this=0x2e92a60) at qml/ftw/qqmlthread.cpp:141
#7  0x00007f7647d5d46b in QThreadPrivate::start (arg=0x2e92a60) at thread/qthread_unix.cpp:337
#8  0x00007f7648c58314 in start_thread (arg=0x7f761c1eb700) at pthread_create.c:333
#9  0x00007f76491c6bbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 2 (Thread 0x7f7612430700 (LWP 23922)):
#0  pthread_cond_wait () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007f764768825b in QTWTF::TCMalloc_PageHeap::scavengerThread (this=0x7f7647771c60 <QTWTF::pageheap_memory>) at ../3rdparty/javascriptcore/JavaScriptCore/wtf/FastMalloc.cpp:2359
#2  0x00007f7647688289 in QTWTF::TCMalloc_PageHeap::runScavengerThread (context=<optimized out>) at ../3rdparty/javascriptcore/JavaScriptCore/wtf/FastMalloc.cpp:1464
#3  0x00007f7648c58314 in start_thread (arg=0x7f7612430700) at pthread_create.c:333
#4  0x00007f76491c6bbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 1 (Thread 0x7f763bd2b800 (LWP 23904)):
[KCrash Handler]
#6  QHash<QHashedStringRef, QQmlType*>::size (this=0x10) at /usr/include/qt5/QtCore/qhash.h:315
#7  QHash<QHashedStringRef, QQmlType*>::values (this=0x10) at /usr/include/qt5/QtCore/qhash.h:705
#8  0x00007f7643fcdf8f in QQmlMetaType::qmlSingletonTypes () at qml/qqmlmetatype.cpp:1864
#9  0x00007f7643fa4628 in QQmlEngine::~QQmlEngine (this=0x1abe870, __in_chrg=<optimized out>) at qml/qqmlengine.cpp:918
#10 0x00007f7643fa47b9 in QQmlEngine::~QQmlEngine (this=0x1abe870, __in_chrg=<optimized out>) at qml/qqmlengine.cpp:924
#11 0x00007f7649115979 in __run_exit_handlers (status=status@entry=1, listp=0x7f76494715c0 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:82
#12 0x00007f76491159c5 in __GI_exit (status=status@entry=1) at exit.c:104
#13 0x00007f76491c4965 in __GI_verrx (status=1, format=<optimized out>, ap=ap@entry=0x7ffcf5710f08) at err.c:165
#14 0x00007f76491c4a8f in errx (status=status@entry=1, format=format@entry=0x7f764486b738 "Couldn't find current GLX or EGL context.\n") at err.c:178
#15 0x00007f76448220e3 in epoxy_get_proc_address (name=<optimized out>) at /var/tmp/portage/media-libs/libepoxy-1.2/work/libepoxy-1.2/src/dispatch_common.c:614
#16 epoxy_get_proc_address (name=0x7f7644872bce <entrypoint_strings+8206> "glDeleteProgram") at /var/tmp/portage/media-libs/libepoxy-1.2/work/libepoxy-1.2/src/dispatch_common.c:592
#17 0x00007f7644860d9d in epoxy_glDeleteProgram_resolver () at gl_generated_dispatch.c:12432
#18 epoxy_glDeleteProgram_global_rewrite_ptr (program=28) at gl_generated_dispatch.c:40733
#19 0x00007f76494d755a in KWin::GLSLBlurShader::reset (this=this@entry=0x1a58560) at /var/tmp/portage/kde-plasma/kwin-5.4.0/work/kwin-5.4.0/effects/blur/blurshader.cpp:125
#20 0x00007f76494d75b3 in KWin::GLSLBlurShader::~GLSLBlurShader (this=0x1a58560, __in_chrg=<optimized out>) at /var/tmp/portage/kde-plasma/kwin-5.4.0/work/kwin-5.4.0/effects/blur/blurshader.cpp:120
#21 KWin::GLSLBlurShader::~GLSLBlurShader (this=0x1a58560, __in_chrg=<optimized out>) at /var/tmp/portage/kde-plasma/kwin-5.4.0/work/kwin-5.4.0/effects/blur/blurshader.cpp:121
#22 0x00007f76494d58dc in KWin::BlurEffect::~BlurEffect (this=0x197aeb0, __in_chrg=<optimized out>) at /var/tmp/portage/kde-plasma/kwin-5.4.0/work/kwin-5.4.0/effects/blur/blur.cpp:70
#23 0x00007f76494d5989 in KWin::BlurEffect::~BlurEffect (this=0x197aeb0, __in_chrg=<optimized out>) at /var/tmp/portage/kde-plasma/kwin-5.4.0/work/kwin-5.4.0/effects/blur/blur.cpp:72
#24 0x00007f7648fbdeae in KWin::EffectsHandlerImpl::~EffectsHandlerImpl (this=0x3ffe9e0, __in_chrg=<optimized out>) at /var/tmp/portage/kde-plasma/kwin-5.4.0/work/kwin-5.4.0/effects.cpp:335
#25 0x00007f7648fbe119 in KWin::EffectsHandlerImpl::~EffectsHandlerImpl (this=0x3ffe9e0, __in_chrg=<optimized out>) at /var/tmp/portage/kde-plasma/kwin-5.4.0/work/kwin-5.4.0/effects.cpp:338
#26 0x00007f7648f7f8b3 in KWin::Compositor::finish (this=this@entry=0x19ac850) at /var/tmp/portage/kde-plasma/kwin-5.4.0/work/kwin-5.4.0/composite.cpp:384
#27 0x00007f7648f7ff8f in KWin::Compositor::slotReinitialize (this=0x19ac850) at /var/tmp/portage/kde-plasma/kwin-5.4.0/work/kwin-5.4.0/composite.cpp:489
#28 0x00007f76490471d3 in KWin::Compositor::qt_metacall (this=0x19ac850, _c=QMetaObject::InvokeMetaMethod, _id=6, _a=0x7ffcf57112e0) at /var/tmp/portage/kde-plasma/kwin-5.4.0/work/kwin-5.4.0_build/moc_composite.cpp:317
#29 0x00007f7643a2951f in QDBusConnectionPrivate::deliverCall (this=0x18f1be0, object=0x19ac850, msg=..., metaTypes=..., slotIdx=11) at qdbusintegrator.cpp:993
#30 0x00007f7647f76296 in QObject::event (this=0x19ac850, e=<optimized out>) at kernel/qobject.cpp:1245
#31 0x00007f764875f86c in QApplicationPrivate::notify_helper (this=this@entry=0x18a0050, receiver=receiver@entry=0x19ac850, e=e@entry=0x55c2b50) at kernel/qapplication.cpp:3720
#32 0x00007f7648764680 in QApplication::notify (this=0x7ffcf57119c0, receiver=0x19ac850, e=0x55c2b50) at kernel/qapplication.cpp:3503
#33 0x00007f7647f4495d in QCoreApplication::notifyInternal (this=0x7ffcf57119c0, receiver=0x19ac850, event=event@entry=0x55c2b50) at kernel/qcoreapplication.cpp:935
#34 0x00007f7647f4689f in QCoreApplication::sendEvent (event=0x55c2b50, receiver=<optimized out>) at kernel/qcoreapplication.h:228
#35 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x18901b0) at kernel/qcoreapplication.cpp:1552
#36 0x00007f7647f9bfcb in QEventDispatcherUNIX::processEvents (this=0x18d6780, flags=flags@entry=...) at kernel/qeventdispatcher_unix.cpp:579
#37 0x00007f763bb2f7bd in QUnixEventDispatcherQPA::processEvents (this=<optimized out>, flags=...) at eventdispatchers/qunixeventdispatcher.cpp:62
#38 0x00007f7647f427eb in QEventLoop::exec (this=this@entry=0x7ffcf57118e0, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204
#39 0x00007f7647f4a23f in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1188
#40 0x00007f764826205c in QGuiApplication::exec () at kernel/qguiapplication.cpp:1507
#41 0x00007f764875bf25 in QApplication::exec () at kernel/qapplication.cpp:2956
#42 0x00007f7649650497 in kdemain (argc=2, argv=0x7ffcf5711b28) at /var/tmp/portage/kde-plasma/kwin-5.4.0/work/kwin-5.4.0/main_x11.cpp:303
#43 0x00007f7649100855 in __libc_start_main (main=0x400780 <main(int, char**)>, argc=2, argv=0x7ffcf5711b28, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffcf5711b18) at libc-start.c:289
#44 0x00000000004007b9 in _start ()

Possible duplicates by query: bug 342130, bug 342129.

Reported using DrKonqi
Comment 1 Thomas Lübking 2015-09-12 06:49:13 UTC
> this=0x10

=)

There's an apparent stack corruption and it *seems* to be caused when libepoxy tries to resolve glDeleteProgram from the GLX library - can you please attach the output of "glxinfo -l"?
Comment 2 A. Wilcox (awilfox) 2015-09-12 16:09:30 UTC
Created attachment 94520 [details]
glxinfo -l output

Here you are: this is the output of glxinfo -l on the affected system.
Comment 3 Thomas Lübking 2015-09-12 18:39:00 UTC
> OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.0.0-rc2
Did you have those problems with stable MESA versions and/or were they 10.5 and did you thus run into https://bugs.freedesktop.org/show_bug.cgi?id=86281 ?
Comment 4 A. Wilcox (awilfox) 2015-09-12 20:03:16 UTC
I upgraded to Mesa 11.0 from 10.6.5 partially to see if it would fix the errors with KDE.  Gentoo has dri3 enabled by default (and has for quite a while), so I don't think it's the same as the linked bug.

I can't reproduce this issue using _any_ non-KDE application.  I've had a few crashes in plasma-shell and many, many crashes in KWin; but I haven't had any crashes marathoning h264 video in VLC-Qt, or playing Minecraft for a few hours, or watching 1080p WebM in Firefox.  I would assume that if the error was deeper in Mesa, it would be affecting other applications.

I went back to Plasma 4 for a day, and it was completely stable.  However, Plasma 5 runs with significantly less power usage - 4 idles my laptop around 70°, while 5 happily idles around 49°.  Plus, I already jumped ship and went to the new KDE SC apps which don't seem to run very well under Plasma 4.   So I would really really like to help improve Plasma 5 if I can.

A new fun thing it's doing now is when rolling the cursor over a menu (whether the KDE application launcher, or app menus like File/Edit/View/Help, the tab menu in Firefox, or even Alt+Tab), selections won't highlight every other option that the cursor rolls under.  For example, if I go in the launcher and mouse over each category, Education, Graphics, and Multimedia show highlighted while the cursor is over them, but Development, Games, and Internet never appear highlighted.  They are still clickable though.  I'm not sure if this is a separate bug and I'm not sure if it persists after an X restart, but I'd be happy to attach gdb to a process if it would help.
Comment 5 Thomas Lübking 2015-09-12 21:01:57 UTC
(In reply to Andrew Wilcox from comment #4)

> I can't reproduce this issue using _any_ non-KDE application.  I've had a
> few crashes in plasma-shell and many, many crashes in KWin; but I haven't
> had any crashes marathoning h264 video in VLC-Qt, or playing Minecraft for a
> few hours, or watching 1080p WebM in Firefox.  I would assume that if the
> error was deeper in Mesa, it would be affecting other applications.

We need more backtraces (or ideally a valgrind log on a crashing application) since stack corruptions make it impossible to blame a certain position (we know the stack got corrupted at some point - that's it)
If you can, provide backtraces from crashes while just running KWin GLX, not on changing the system.

The backtrace you posted points to libepoxy and then to QtQuick - which *may* be the link between kwin and plasmashell (and makes use of OpenGL)
The problem *may* also be in the massive amount of parallel GL contexts that the QtQuick usage implies (eg. every plasmashell tooltip is one)

Watching videos would only be relevant if you used the GL sink of the player (and not xv or vdpau etc.)

> A new fun thing it's doing now is when rolling the cursor over a menu
-> bug #352427
Comment 6 A. Wilcox (awilfox) 2015-09-12 23:14:50 UTC
(In reply to Thomas Lübking from comment #5)
> We need more backtraces (or ideally a valgrind log on a crashing
> application) since stack corruptions make it impossible to blame a certain
> position (we know the stack got corrupted at some point - that's it)
> If you can, provide backtraces from crashes while just running KWin GLX, not
> on changing the system.

I could reset the backend to GLX and attach valgrind to KWin, but I am slightly concerned on how large the log could get; it sometimes takes 8 to 12 to even 24 hours before it crashes.

> The backtrace you posted points to libepoxy and then to QtQuick - which
> *may* be the link between kwin and plasmashell (and makes use of OpenGL)
> The problem *may* also be in the massive amount of parallel GL contexts that
> the QtQuick usage implies (eg. every plasmashell tooltip is one)

I make frequent use of the tooltips in the task manager to select which window I want to activate out of the open ones, and I also use tooltips of plasmoids like the temperature gauge, so that is definitely a possibility.

> Watching videos would only be relevant if you used the GL sink of the player
> (and not xv or vdpau etc.)

Yes, I specifically used GL on VLC and Firefox as a sort of "stress test" for the card to make sure it wasn't a hardware issue.

> > A new fun thing it's doing now is when rolling the cursor over a menu
> -> bug #352427

Thanks for the pointer!  I couldn't find that one.  Okay, tomorrow morning I will switch back to GLX and attach valgrind and see if I can make it crash relatively quickly.

My gratitude to you, by the way; not all open source projects are so expedient to respond to bugs and so precise with what info they need and how to obtain it.  Another reason I like KDE :)
Comment 7 Thomas Lübking 2015-09-13 06:26:47 UTC
Running kwin (or anything) in valgrind (over a long time) can be quite a PITA - let's check the backtrace of a runtime segfault first (or we can point a trigger)
Comment 8 A. Wilcox (awilfox) 2015-09-14 19:51:12 UTC
I haven't managed to be "lucky" enough to hit a segfault, but KWin has been in GLX mode for 36 hours now, and these are the disturbances I've noticed:

- Scrolling in Firefox, Chrome, and Dolphin are all messed up, in a very hard to describe way.  It only seems to occur on secondary windows.  I usually have three Firefox windows - the main one is what I use for KDE and Gentoo bug trackers and such (my 'open source' window).  The second one is for my day job, and the third one is for researching (so Google Books, library, and such).  I was scrolling in the third window when it started having this glitch.  I tried to take a screenshot, but then the area directly under the KSnapshot window started scrolling smoothly.  I then raised Kate over Firefox, and scrolled then minimised Kate quickly.  The area that was under the Kate window scrolled perfectly for a good 5-10 seconds before glitching again.  Disabling compositing (Shift+Alt+F12) fixes it - re-enabling it breaks it again.  This only affects the second and third windows, never the first.  I did notice that sometimes(?) Plasma Shell shows three separate Firefox entries on the task bar instead of grouping them, so I'm not sure if KWin is treating them that way too?  An example of when I scrolled immediately after closing KSnapshot (you can see the 'ghost' of its window being the only part of Firefox that scrolls) is at http://foxkit.us/pictures/broken-fx-scroll.png .

- Related to that, it seems that when compositing is active the Plasma Shell panel at the bottom of my screen is split into a top and bottom half, which render separately.  You can see the results at http://foxkit.us/pictures/broken-panel1.png (Pidgin notification icon) and http://foxkit.us/pictures/broken-panel2.png (KSnapshot icon).  There was further fun where minimising Chrome caused it to glitch and show half colour and half greyscale (due to the minimise effect), but I was unable to take a screenshot of it because opening KSnapshot caused it to redraw.

- If I use Alt+Tab to switch windows, the scrolling gesture on my touchpad stops working.  To make it work again I have to tap Alt+Tab quick enough to switch a window without the Alt+Tab window showing.  I assume something about Alt+Tab is 'sticking' or holding the scroll wheel 'hostage' in some way?  This may be a separate bug; if you think I should file it separately, I will.  I didn't find anything about it in the tracker though.

All of these issues only occur when compositing is enabled, and then only on GLX.  I had no issues (other than bug #352427) using EGL.  I would really like to help squash these bugs so if you need me to gather any information, please let me know.
Comment 9 A. Wilcox (awilfox) 2015-09-15 22:33:37 UTC
After a suggestion from someone else, I tried playing with the Desktop Effects preference pane.  Disabling Blur restores scrolling/rendering, but it is still very sluggish.  Scrolling Chrome goes at about 2-3 FPS with compositing enabled, but at least it works at all.  Re-enabling Blur (half or full) makes it completely dead again, as shown in the prior screenshot and in this one (note I was trying to open a new tab when this happened, then alt+tab'd away to try and fix it): http://foxkit.us/pictures/broken-chrome.png - the weirdest part is that border.  I don't understand it, but that border which is exactly 12px on each side always updates, and it always keeps up with scrolling/updating/animating (even when the rest of the window is lagging without Blur or completely dead with Blur).

Disabling or enabling any of the other desktop effects had no effect.  I'm not sure if this is helpful, but hopefully this can at least help narrow down the issue.

One thing I will note that I am not sure many other people do is that I frequently use Zoom (Meta + and Meta -) to read small text and to show others (in real life) parts of my screen.  I'm not sure if this would have anything to do with it.
Comment 10 A. Wilcox (awilfox) 2015-09-16 15:05:15 UTC
Created attachment 94599 [details]
New crash information added by Dr awilfox, filling in for DrKonqi

After I made the above comment, I tried with `export KWIN_USE_BUFFER_AGE=0` and everything was stable for hours.  16 hours and no breakage at all, I was happy.

I was having a chat about this and other things in freenode and the subject of glxgears came up.  I ran it to get the number of FPS and immediately after running glxgears kwin has segfaulted.  Unfortunately KCrash never showed up; it appears to have, hilariously, crashed.

I attached gdb to the crashed kwin.  Output of bt full is attached.  I will do like KCrash:

-- Backtrace (Reduced):
#6  QQmlBoundSignalExpression::function (this=this@entry=0x6272220) at ../../include/QtQml/5.4.2/QtQml/private/../../../../../src/qml/qml/qqmlengine_p.h:155
#7  0x00007fa58617ac28 in QQmlBoundSignalExpression::sourceLocation (this=this@entry=0x6272220) at qml/qqmlboundsignal.cpp:154
#8  0x00007fa58615a4bb in QQmlData::destroyed (this=0x49732f0, object=0x2065440) at qml/qqmlengine.cpp:1615
#9  0x00007fa58a13abed in QObject::~QObject (this=0x2065440, __in_chrg=<optimized out>) at kernel/qobject.cpp:918
#10 0x00007fa5866ee1ee in QQuickItem::~QQuickItem (this=0x2065440, __in_chrg=<optimized out>) at items/qquickitem.cpp:2223
Comment 11 A. Wilcox (awilfox) 2015-09-17 20:45:36 UTC
For what it's worth, `export KWIN_USE_BUFFER_AGE=0` has seemed to fix all the corruption I saw with scrolling and drawing in Firefox, Chrome, Dolphin, et al, and the 'half and half' Plasma panel I showed.  It's been perfect for over 30 hours now with that in place, where before it wouldn't even last 12 hours.

So now it's just these darn QML crashes to sort out.
Comment 12 Thomas Lübking 2015-09-19 07:34:55 UTC
(In reply to Andrew Wilcox from comment #8)
> - If I use Alt+Tab to switch windows, the scrolling gesture on my touchpad
> stops working.  To make it work again I have to tap Alt+Tab quick enough to
> switch a window without the Alt+Tab window showing.  I assume something
> about Alt+Tab is 'sticking' or holding the scroll wheel 'hostage' in some
> way?  This may be a separate bug; if you think I should file it separately,
> I will.  I didn't find anything about it in the tracker though.

Does this *only* happen with GLX compositing?
And the scroll gesture is broken *everywhere* afterwards?

(In reply to Andrew Wilcox from comment #10)
> After I made the above comment, I tried with `export KWIN_USE_BUFFER_AGE=0`
> and everything was stable for hours.  16 hours and no breakage at all, I was
> happy.

This means neither the problems in the plasmashell nor the scrolling issues nor even the loss of scrolling gesture (two finger move? did the edge move still work?) occur?

> I attached gdb to the crashed kwin.  Output of bt full is attached.  I will
> do like KCrash.

That's bug #346857 - QML issue, the cause is the aurorae decoration engine. Use breeze. 

(In reply to Andrew Wilcox from comment #11)
> So now it's just these darn QML crashes to sort out.
QtQuick unfortunately crashes all over the place, the actual cause was the aurorae decoration engine, plastik will likely cause you the same.

The "solution" to "export KWIN_USE_BUFFER_AGE=0" largely sounds like a driver bug.
It's either a problem of buffer age implementation when using multiple GLX contexts or of swap control. Do things still work if you keep the variable exported, but set the "tearing prevention" to "full scene repaints"? (do *NOT* and i mean *NEVER* try to copy the front buffer!)
Comment 13 A. Wilcox (awilfox) 2015-09-19 17:59:04 UTC
(In reply to Thomas Lübking from comment #12)
> Does this *only* happen with GLX compositing?
> And the scroll gesture is broken *everywhere* afterwards?

That is correct.


> (In reply to Andrew Wilcox from comment #10)
> > After I made the above comment, I tried with `export KWIN_USE_BUFFER_AGE=0`
> > and everything was stable for hours.  16 hours and no breakage at all, I was
> > happy.
> 
> This means neither the problems in the plasmashell nor the scrolling issues
> nor even the loss of scrolling gesture (two finger move? did the edge move
> still work?) occur?

The plasmashell problems, scrolling breakage, panel issues, glitches, etc all went away.  The scrolling gesture still does not work when alt+tab "wedges".  Actually no touchpad gestures work after alt+tab; not just scrolling (two finger and edge) but also three-finger-tap for middle button stops working.  I can file a separate bug as I said.


> That's bug #346857 - QML issue, the cause is the aurorae decoration engine.
> Use breeze. 

Oh, I didn't know that.  Sorry.


> (In reply to Andrew Wilcox from comment #11)
> > So now it's just these darn QML crashes to sort out.
> QtQuick unfortunately crashes all over the place, the actual cause was the
> aurorae decoration engine, plastik will likely cause you the same.

Is there any hope for fixing this?  Or I suppose I can live with the crashes.  Not a huge fan of the Breeze decorations myself.  I like PlastiK a whole lot, so I can live with those crashes if they aren't harmful/indicative of a problem other than QtQuick is a beast.


> The "solution" to "export KWIN_USE_BUFFER_AGE=0" largely sounds like a
> driver bug.
> It's either a problem of buffer age implementation when using multiple GLX
> contexts or of swap control. Do things still work if you keep the variable
> exported, but set the "tearing prevention" to "full scene repaints"? (do
> *NOT* and i mean *NEVER* try to copy the front buffer!)

I have just switched the tearing prevention to full screen repaint while leaving KWIN_USE_BUFFER_AGE=0.  We will see if it causes any issues.  It can take many hours (or 1-2 days really) for them to happen, but it is running right now with no breakage.

Thank you again so much for all your help.  It probably is a driver bug that was just never hit before because KWin 5 is much more shiny and using more of the GPU than KWin 4.
Comment 14 A. Wilcox (awilfox) 2015-09-19 18:37:26 UTC
That didn't take long.  Plasma shell isn't painting at all - it's 13:21 local time and the panel still shows 13:08.  In fact:

32042 awilcox   20   0 4599.6m 1.600g 400.0 10.3 401:07.95 R plasmashell

It is changing between 0.0% and 400.0% CPU usage.  I was changing some settings since I already had System Settings open: specifically, I was tweaking the colours of my theme.

#0  QCoreApplication::removePostedEvents (receiver=0x576efca0, eventType=eventType@entry=0) at kernel/qcoreapplication.cpp:1609
#1  0x00007f53fc9c31f1 in QObjectPrivate::~QObjectPrivate (this=0x2be3a7b0, __in_chrg=<optimized out>) at kernel/qobject.cpp:234
#2  0x00007f53fc9c3329 in QObjectPrivate::~QObjectPrivate (this=0x2be3a7b0, __in_chrg=<optimized out>) at kernel/qobject.cpp:245
#3  0x00007f53fc9cdfb2 in QScopedPointerDeleter<QObjectData>::cleanup (pointer=<optimized out>) at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:54
#4  QScopedPointer<QObjectData, QScopedPointerDeleter<QObjectData> >::~QScopedPointer (this=0x576efca8, __in_chrg=<optimized out>) at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:101
#5  QObject::~QObject (this=<optimized out>, __in_chrg=<optimized out>) at kernel/qobject.cpp:882
#6  0x00007f53f1559d62 in Breeze::AnimationData::~AnimationData (this=0x576efca0, __in_chrg=<optimized out>)
    at /var/tmp/portage/kde-plasma/breeze-5.4.0/work/breeze-5.4.0-kf5/kstyle/../../breeze-5.4.0/kstyle/animations/breezeanimationdata.h:51
#7  Breeze::GenericData::~GenericData (this=0x576efca0, __in_chrg=<optimized out>)
    at /var/tmp/portage/kde-plasma/breeze-5.4.0/work/breeze-5.4.0-kf5/kstyle/../../breeze-5.4.0/kstyle/animations/breezegenericdata.h:48
#8  Breeze::WidgetStateData::~WidgetStateData (this=0x576efca0, __in_chrg=<optimized out>)
    at /var/tmp/portage/kde-plasma/breeze-5.4.0/work/breeze-5.4.0-kf5/kstyle/../../breeze-5.4.0/kstyle/animations/breezewidgetstatedata.h:45
#9  Breeze::EnableData::~EnableData (this=0x576efca0, __in_chrg=<optimized out>)
    at /var/tmp/portage/kde-plasma/breeze-5.4.0/work/breeze-5.4.0-kf5/kstyle/../../breeze-5.4.0/kstyle/animations/breezeenabledata.h:43
#10 Breeze::EnableData::~EnableData (this=0x576efca0, __in_chrg=<optimized out>)
    at /var/tmp/portage/kde-plasma/breeze-5.4.0/work/breeze-5.4.0-kf5/kstyle/../../breeze-5.4.0/kstyle/animations/breezeenabledata.h:43
#11 0x00007f53fc9c3c5b in QObjectPrivate::deleteChildren (this=this@entry=0x37d515d0) at kernel/qobject.cpp:1950
#12 0x00007f53fc9cdf6c in QObject::~QObject (this=<optimized out>, __in_chrg=<optimized out>) at kernel/qobject.cpp:1030
#13 0x00007f53f155b2ed in Breeze::BaseEngine::~BaseEngine (this=0x46f48520, __in_chrg=<optimized out>)
    at /var/tmp/portage/kde-plasma/breeze-5.4.0/work/breeze-5.4.0-kf5/kstyle/../../breeze-5.4.0/kstyle/animations/breezebaseengine.h:51
#14 Breeze::WidgetStateEngine::~WidgetStateEngine (this=0x46f48520, __in_chrg=<optimized out>)
    at /var/tmp/portage/kde-plasma/breeze-5.4.0/work/breeze-5.4.0-kf5/kstyle/../../breeze-5.4.0/kstyle/animations/breezewidgetstateengine.h:46
#15 Breeze::WidgetStateEngine::~WidgetStateEngine (this=0x46f48520, __in_chrg=<optimized out>)
    at /var/tmp/portage/kde-plasma/breeze-5.4.0/work/breeze-5.4.0-kf5/kstyle/../../breeze-5.4.0/kstyle/animations/breezewidgetstateengine.h:46
#16 0x00007f53fc9c3c5b in QObjectPrivate::deleteChildren (this=this@entry=0x37d51ea0) at kernel/qobject.cpp:1950
#17 0x00007f53fc9cdf6c in QObject::~QObject (this=<optimized out>, __in_chrg=<optimized out>) at kernel/qobject.cpp:1030
#18 0x00007f53f1559f1f in Breeze::Animations::~Animations (this=0x5aa640c0, __in_chrg=<optimized out>)
    at /var/tmp/portage/kde-plasma/breeze-5.4.0/work/breeze-5.4.0-kf5/kstyle/../../breeze-5.4.0/kstyle/animations/breezeanimations.h:52
#19 Breeze::Animations::~Animations (this=0x5aa640c0, __in_chrg=<optimized out>)
    at /var/tmp/portage/kde-plasma/breeze-5.4.0/work/breeze-5.4.0-kf5/kstyle/../../breeze-5.4.0/kstyle/animations/breezeanimations.h:52
#20 0x00007f53fc9c3c5b in QObjectPrivate::deleteChildren (this=this@entry=0x47717ff0) at kernel/qobject.cpp:1950
#21 0x00007f53fc9cdf6c in QObject::~QObject (this=<optimized out>, __in_chrg=<optimized out>) at kernel/qobject.cpp:1030
#22 0x00007f53f15390a9 in Breeze::Style::~Style (this=0x52d4fdc0, __in_chrg=<optimized out>) at /var/tmp/portage/kde-plasma/breeze-5.4.0/work/breeze-5.4.0/kstyle/breezestyle.cpp:206
#23 0x00007f53fd23f6e4 in QApplication::setStyle (style=<optimized out>) at kernel/qapplication.cpp:1263
#24 0x00007f53fd23fe66 in QApplication::setStyle (style=...) at kernel/qapplication.cpp:1295
#25 0x00007f53f1cd77a3 in KHintsSettings::slotNotifyChange (this=0xc30cd0, type=<optimized out>, arg=<optimized out>)
    at /var/tmp/portage/kde-frameworks/frameworkintegration-5.13.0/work/frameworkintegration-5.13.0/src/platformtheme/khintssettings.cpp:274
#26 0x00007f53f1ce1fd3 in KHintsSettings::qt_metacall (this=0xc30cd0, _c=QMetaObject::InvokeMetaMethod, _id=3, _a=0x7fff9640f220)
    at /var/tmp/portage/kde-frameworks/frameworkintegration-5.13.0/work/frameworkintegration-5.13.0_build/src/platformtheme/moc_khintssettings.cpp:116
#27 0x00007f53fd07651f in QDBusConnectionPrivate::deliverCall (this=0xc523c0, object=0xc30cd0, msg=..., metaTypes=..., slotIdx=8) at qdbusintegrator.cpp:993
#28 0x00007f53fc9c6296 in QObject::event (this=0xc30cd0, e=<optimized out>) at kernel/qobject.cpp:1245
#29 0x00007f53fd23d86c in QApplicationPrivate::notify_helper (this=this@entry=0xc00b70, receiver=receiver@entry=0xc30cd0, e=e@entry=0x4b8897c0) at kernel/qapplication.cpp:3720
#30 0x00007f53fd242680 in QApplication::notify (this=0x7fff9640fa50, receiver=0xc30cd0, e=0x4b8897c0) at kernel/qapplication.cpp:3503
#31 0x00007f53fc99495d in QCoreApplication::notifyInternal (this=0x7fff9640fa50, receiver=0xc30cd0, event=event@entry=0x4b8897c0) at kernel/qcoreapplication.cpp:935
#32 0x00007f53fc99689f in QCoreApplication::sendEvent (event=0x4b8897c0, receiver=<optimized out>) at kernel/qcoreapplication.h:228
#33 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0xbf61f0) at kernel/qcoreapplication.cpp:1552
#34 0x00007f53fc996f08 in QCoreApplication::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1410
#35 0x00007f53fc9eeae3 in postEventSourceDispatch (s=0xc33d00) at kernel/qeventdispatcher_glib.cpp:271
#36 0x00007f53f95479c4 in g_main_dispatch (context=0x7f53ec002450) at /var/tmp/portage/dev-libs/glib-2.44.1/work/glib-2.44.1/glib/gmain.c:3122
#37 g_main_context_dispatch (context=context@entry=0x7f53ec002450) at /var/tmp/portage/dev-libs/glib-2.44.1/work/glib-2.44.1/glib/gmain.c:3737
#38 0x00007f53f9547c18 in g_main_context_iterate (context=context@entry=0x7f53ec002450, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at /var/tmp/portage/dev-libs/glib-2.44.1/work/glib-2.44.1/glib/gmain.c:3808
#39 0x00007f53f9547cbc in g_main_context_iteration (context=0x7f53ec002450, may_block=1) at /var/tmp/portage/dev-libs/glib-2.44.1/work/glib-2.44.1/glib/gmain.c:3869
#40 0x00007f53fc9edf2c in QEventDispatcherGlib::processEvents (this=0xc34090, flags=...) at kernel/qeventdispatcher_glib.cpp:418
#41 0x00007f53fc9927eb in QEventLoop::exec (this=this@entry=0x7fff9640f8c0, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204
#42 0x00007f53fc99a23f in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1188
#43 0x00007f53fccb205c in QGuiApplication::exec () at kernel/qguiapplication.cpp:1507
#44 0x00007f53fd239f25 in QApplication::exec () at kernel/qapplication.cpp:2956
#45 0x000000000043218b in main (argc=2, argv=<optimized out>) at /var/tmp/portage/kde-plasma/plasma-workspace-5.4.0/work/plasma-workspace-5.4.0/shell/main.cpp:176


I am not sure if this is more Qt breakage or if this is maybe in Breeze - while I use plastik window decoration, I use the Breeze widgets.  I didn't find any related bugs looking up 'removePostedEvents', they all seem to be crashes.  This is locked up, not crashed.  The backtrace doesn't change after letting it spin for 60 seconds and then re-attaching.  Should this be filed as a separate bug too?  I don't want to pollute the bugzilla, I apologise.

I wrote a core file for further debugging if necessary, and have relaunched plasmashell.  I don't think this was related to the vsync change as it occurred when I changed colours in the system settings but I'm just noting it here.
Comment 15 Thomas Lübking 2015-09-19 21:07:51 UTC
The backtrace include the breeze GUI style, not the decoration.
Actually, the style is reset at this point (thus the present object deleted)

QCoreApplication::removePostedEvents() at this point tries to claim a mutex - the same one QCoreApplicationPrivate::sendPostedEvents() just obtained (delivering the dbus call to reset the style...)

= I don't think this is any related to this bug or the compositor painting (unless for a driver induced stack corruption) =

I've never seen such but either QApplication should call old->deleteLater() in QApplication::setStyle or KHintsSettings::slotNotifyChange should avoid to call QApplication::setStyle ("never delete a QObject directly in a slot" policy)

Since the latter would defeat the purpose, KHintsSettings::slotNotifyChange would likely have to call QCoreApplication::sendPostedEvents() before setting the style. -> framework integration, platformtheme component. Feel free to CC me ;-)
Comment 16 A. Wilcox (awilfox) 2015-09-20 02:01:43 UTC
In re the other bug, noted.  I will file it later tonight or tomorrow.

It has just died in the same way it used to, with full screen repaint on.  Switching back to auto fixed scrolling and repainting everywhere.  I'm not sure what that means, but yes, full screen repaint turned on made KWIN_USE_BUFFER_AGE=0 useless.
Comment 17 Thomas Lübking 2015-09-20 06:08:28 UTC
It will increase (synced) buffer swapping (just as re-using the old buffer)

The cross-test is to leave buffer age enabled, but set tearing prevention to none (what will re-use the buffer and swap, but not wait for vblank signals)
Comment 18 A. Wilcox (awilfox) 2015-09-20 18:07:14 UTC
I was still running it the other way (KWIN_USE_BUFFER_AGE=0, auto vsync) and kwin segfaulted when I tried to open an app.  I have no clue what the backtrace is because DrKonqi segfaulted while loading the segfault info from kwin, which caused it to go away.  That is very unhelpful, I know, and it is very frustrating.  I have exported KDE_DEBUG=1 so that it just generates core files which I can use since DrKonqi seems to really hate KWin being dead.

All I know is that it printed "failed to create drawable" on stdout right before the crash.

I am so very annoyed, it happens so infrequently and this would have been a great backtrace had it existed at all.

I guess I will re-enable buffer age (so no export KWIN_USE_BUFFER_AGE at all), and set vsync to None, and see how things go to do the other test.
Comment 19 A. Wilcox (awilfox) 2015-09-23 00:45:26 UTC
(The other bug about Breeze was filed as bug 352951 in case you missed it.)

Those settings gave me some distance, but it has started failing in pretty spectacular ways now.  I thought SSH was lagging or my Internet connection died, but it turns out that now Konsole is not updating views unless I minimise and restore or switch to other windows.  This is the same behaviour I was seeing in Chrome and Firefox, only now it's severely impeding my productivity.  In fact, even local sessions have severe typing lag; it reminds me of using a 3G modem except it's local and drawing-related instead of actual input.

It would also appear that plasmashell has stopped updating the clock about an hour ago.  It shows 18:41, even though it's 19:39 local right now.

So: KWIN_USE_BUFFER_AGE unset + vsync None = a usable desktop for about two days before everything falls apart even worse than before.  Should I be filing a bug upstream with Mesa?  Or Qt?  I guess KWIN_USE_BUFFER_AGE=0 works so that is a usable workaround.
Comment 20 A. Wilcox (awilfox) 2015-09-26 21:43:17 UTC
Not sure if this is interesting or not.  I have meta+number keys assigned to quick launch apps.  Meta+3 is Kate, when I tapped it this afternoon I got a 2.8GB core dump from KWin and this is the backtrace:

Core was generated by `kwin_x11 --replace'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f5a0544a157 in __GI_raise (sig=11) at ../sysdeps/unix/sysv/linux/raise.c:55
55      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f59fa06a800 (LWP 16378))]
(gdb) bt
#0  0x00007f5a0544a157 in __GI_raise (sig=11) at ../sysdeps/unix/sysv/linux/raise.c:55
#1  0x00007f5a0210f93b in KCrash::defaultCrashHandler (sig=11) at /var/tmp/portage/kde-frameworks/kcrash-5.13.0/work/kcrash-5.13.0/src/kcrash.cpp:409
#2  <signal handler called>
#3  dri2SetSwapInterval (pdraw=0x0, interval=1) at /var/tmp/portage/media-libs/mesa-11.0.0/work/mesa-11.0.0/src/glx/dri2_glx.c:919
#4  0x00007f59f9e41041 in QGLXContext::makeCurrent (this=0x2d058a0, surface=<optimized out>) at qglxintegration.cpp:506
#5  0x00007f5a045d30bf in QOpenGLContext::makeCurrent (this=0x4e69da0, surface=0x5070660) at kernel/qopenglcontext.cpp:898
#6  0x00007f59f273a042 in Aurorae::Decoration::init (this=0x7d8c100) at /var/tmp/portage/kde-plasma/kwin-5.4.0/work/kwin-5.4.0/clients/aurorae/src/aurorae.cpp:382
#7  0x00007f5a0533d6a5 in KWin::Decoration::DecorationBridge::createDecoration (this=0x1d389b0, client=client@entry=0x503b1f0)
    at /var/tmp/portage/kde-plasma/kwin-5.4.0/work/kwin-5.4.0/decorations/decorationbridge.cpp:213
#8  0x00007f5a05234b91 in KWin::Client::createDecoration (this=this@entry=0x503b1f0, oldgeom=...) at /var/tmp/portage/kde-plasma/kwin-5.4.0/work/kwin-5.4.0/client.cpp:409
#9  0x00007f5a052356bb in KWin::Client::updateDecoration (this=this@entry=0x503b1f0, check_workspace_pos=check_workspace_pos@entry=false, force=force@entry=false)
    at /var/tmp/portage/kde-plasma/kwin-5.4.0/work/kwin-5.4.0/client.cpp:396
#10 0x00007f5a05281962 in KWin::Client::manage (this=this@entry=0x503b1f0, w=w@entry=60817823, isMapped=isMapped@entry=false) at /var/tmp/portage/kde-plasma/kwin-5.4.0/work/kwin-5.4.0/manage.cpp:385
#11 0x00007f5a0521c5cb in KWin::Workspace::createClient (this=this@entry=0x1d21350, w=60817823, is_mapped=is_mapped@entry=false) at /var/tmp/portage/kde-plasma/kwin-5.4.0/work/kwin-5.4.0/workspace.cpp:485
#12 0x00007f5a0526a7a3 in KWin::Workspace::workspaceEvent (this=0x1d21350, e=0x7f59f4003e70) at /var/tmp/portage/kde-plasma/kwin-5.4.0/work/kwin-5.4.0/events.cpp:419
#13 0x00007f5a042789df in QAbstractEventDispatcher::filterNativeEvent (this=this@entry=0x1c5dfc0, eventType=..., message=message@entry=0x7f59f4003e70, result=result@entry=0x7fff7d7b4348)
    at kernel/qabstracteventdispatcher.cpp:460
#14 0x00007f59f9e194ed in QXcbConnection::handleXcbEvent (this=this@entry=0x1c30970, event=event@entry=0x7f59f4003e70) at qxcbconnection.cpp:863
#15 0x00007f59f9e1a84b in QXcbConnection::processXcbEvents (this=0x1c30970) at qxcbconnection.cpp:1303
#16 0x00007f5a042ad296 in QObject::event (this=0x1c30970, e=<optimized out>) at kernel/qobject.cpp:1245
#17 0x00007f5a04a9686c in QApplicationPrivate::notify_helper (this=this@entry=0x1c2a060, receiver=receiver@entry=0x1c30970, e=e@entry=0x7f59f40060a0) at kernel/qapplication.cpp:3720
#18 0x00007f5a04a9b680 in QApplication::notify (this=0x7fff7d7b4b30, receiver=0x1c30970, e=0x7f59f40060a0) at kernel/qapplication.cpp:3503
#19 0x00007f5a0427b95d in QCoreApplication::notifyInternal (this=0x7fff7d7b4b30, receiver=0x1c30970, event=event@entry=0x7f59f40060a0) at kernel/qcoreapplication.cpp:935
#20 0x00007f5a0427d89f in QCoreApplication::sendEvent (event=0x7f59f40060a0, receiver=<optimized out>) at kernel/qcoreapplication.h:228
#21 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x1c1a1b0) at kernel/qcoreapplication.cpp:1552
#22 0x00007f5a042d2fcb in QEventDispatcherUNIX::processEvents (this=0x1c5dfc0, flags=flags@entry=...) at kernel/qeventdispatcher_unix.cpp:579
#23 0x00007f59f9e6e7bd in QUnixEventDispatcherQPA::processEvents (this=<optimized out>, flags=...) at eventdispatchers/qunixeventdispatcher.cpp:62
#24 0x00007f5a042797eb in QEventLoop::exec (this=this@entry=0x7fff7d7b4a60, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204
#25 0x00007f5a0428123f in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1188
#26 0x00007f5a0459905c in QGuiApplication::exec () at kernel/qguiapplication.cpp:1507
#27 0x00007f5a04a92f25 in QApplication::exec () at kernel/qapplication.cpp:2956
#28 0x00007f5a05987497 in kdemain (argc=2, argv=0x7fff7d7b4c98) at /var/tmp/portage/kde-plasma/kwin-5.4.0/work/kwin-5.4.0/main_x11.cpp:303
#29 0x00007f5a05437855 in __libc_start_main (main=0x400780 <main(int, char**)>, argc=2, argv=0x7fff7d7b4c98, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff7d7b4c88)
    at libc-start.c:289
#30 0x00000000004007b9 in _start ()

I can do further stuff with gdb if this is at all interesting.  I guess this bug has turned pretty useless, since it basically "bug 352548 - my laptop has random crashes in kwin" now.  Still, I hope to maybe someday have some of them resolved...
Comment 21 Thomas Lübking 2015-09-27 20:39:16 UTC
That's https://bugs.freedesktop.org/show_bug.cgi?id=89562
The 3GB coredump however sounds like some leak somewhere - does kwin at some point start using excessive amounts of memory as well?

(In reply to Andrew Wilcox from comment #19)

> Those settings gave me some distance, but it has started failing in pretty
> spectacular ways now.  I thought SSH was lagging or my Internet connection
> died, but it turns out that now Konsole is not updating views unless I
> minimise and restore or switch to other windows.

No even if you eg. select text or scroll?
Sounds as if the texture gets disconnected from the window. (what could relate to a potential memory leak)
If there's no apparent leak: does resizing the konsole window "repair" it (for the next two days)?
Comment 22 A. Wilcox (awilfox) 2015-10-03 07:49:43 UTC
Resizing windows when they are broken doesn't help at all; only restarting kwin.

The same dri2SetSwapInterval crash just happened to me again, I am annoyed at mesa developers now.  This bug has been "NEW" since March and they seem to not care.

KWin isn't super leaky; it was at about 600MB usage at 3 days uptime when it crashed 20 minutes ago.  I've seen it grow to a gig.  Honestly after using Mac OS X, Firefox, Inkscape, Chrome, and the like for years… I've started to just ignore memory leaks.  They're a fact of life and nobody seems to care when I report them.  The fact that you even mentioned it is refreshing and awesome.  How would I be able to help debug?  Plasma Shell regularly balloons to 2gb or so, too, I have to kquitapp5 && kshell5 it regularly to keep memory usage sane.
Comment 23 Thomas Lübking 2015-10-03 20:11:37 UTC
Depending on the memory layout, KWin's memory requirement can be quite high (w/ active compositor, if the window textures show up in system ram. Should then drop drastically w/ suspending the compositor. This is reflected in "xrestop" for sure by KWin's high pixmap memory usage)

Otherwise, 600M is *far* too much. kwin_x11 is residual w/ 120M here.
If there's a leak in the texture memory share, it probably doesn't matter where it is to trigger the dri2SetSwapInterval crash (ie. plasmashell could theoretically crash kwin by causing an OOM condition)

In any suspect of memleaks: valgrind knows the answer ;-)
Comment 24 A. Wilcox (awilfox) 2015-11-07 08:04:35 UTC
You know, I have given up entirely on that laptop.  It was starting to fail in other ways (stack was corrupted in random places and so on).  I got myself a new desktop.

Lots of problems with the Radeon HD 6450 it came with, including a tonne of bugs that I should file separately, but I swapped in a 5770 and was having no issues.  I was very happy!  But tonight, it has started all over again.

Right now, Chrome is no longer updating itself again, just like comment 8 in this bug.  So far no other software are affected.  I really am at a loss on how to even debug or try to fix this bug..  uptime reports "up 1 day,  3:08"; I guess again it takes somewhere around 12 hours for this bug to start.

Since that comment, I have gotten a pair of glasses so I no longer need to use Meta+/- to zoom the screen.  I haven't used it once on this desktop (and indeed since my glasses I forgot all about the feature entirely), so I no longer believe that has anything to do with it.

Interesting points are that the 5770 uses EGL, not GLX, so this issue seems to have nothing to do with that.  Also, it uses OpenGL 3.3, not 2.0, so it seems to not have anything to do with GL version.
Comment 25 A. Wilcox (awilfox) 2015-11-07 08:15:42 UTC
Created attachment 95367 [details]
KWin supportInformation

This is the output of `qdbus org.kde.KWin /KWin supportInformation` right now on the system with the Radeon HD 5770.  Note it is different to my old Sandy Bridge laptop in almost every way.
Comment 26 Martin Flöser 2015-11-09 07:44:36 UTC
why do you change to EGL and OpenGL 3.3? Please try with default settings. And best restart the system once you changed.
Comment 27 A. Wilcox (awilfox) 2015-11-13 02:56:27 UTC
EGL and OpenGL 3.3 were the default settings on this computer, and in fact, EGL is the /only/ option on this computer.

OpenGL 2.0 does not help, even after a full reboot.  XRender gives a lot of horrible memory leaks in plasmadesktop (which is a separate, known, issue).

Please note that as I said, this is a new desktop experiencing the same symptoms; on my laptop, I was trying to switch GLX to EGL because GLX was giving me a lot of issues.  On this computer, a desktop, it *only* has EGL.
Comment 28 Martin Flöser 2015-11-13 07:03:08 UTC
> EGL and OpenGL 3.3 were the default settings on this computer, and in fact, EGL is the /only/ option on this computer.

Sorry but this doesn't make sense - we certainly do not set it like that. Which distribution are you using?
Comment 29 Thomas Lübking 2015-11-13 07:50:48 UTC
And please paste the output of "xdpyinfo | grep -iA50 extensions"
And what "known issue" about memory leaks in "plasmadesktop" (there's no such binary, so please specify what you mean here) when using xrender as compositor do you mean, please?
Comment 30 Christoph Feck 2017-06-02 18:16:24 UTC
*** Bug 379681 has been marked as a duplicate of this bug. ***
Comment 31 Martin Flöser 2017-07-02 15:12:55 UTC
Switching between GLX and EGL is no longer supported in KWin. The GUI option to select does no longer exist. Closing as it's now a no longer supported corner case.