Created attachment 111758 [details] plasmashell log It seems there's a memory leak in plasma's launchers. It happens both on Application Dashboard and Application Launcher. Steps to reproduce: 1. open KSysGuard and filter plasmashell in the processes. 2. launch Application Launcher and browse the application menus repeatedly, and watch as ram usage increases 3. after a while, close the launcher, open it again, and repeat step 2 This keeps increasing plasmashell's ram usage unstoppably. After a day of work I usually have plasmashell consuming about 1GB ram. Killing plasmashell and starting it again is a workaround. I'm not sure if this can be related, but I have a nvidia card (GTX 970). I posted plasmashell journal in the attachment. Please let me know there's another relevant log to post. Also, I recorded a video showing this issue in action: https://youtu.be/9D4TfWE1_vk
confirmed. Every switch into a deeper menue cost some RAM.
Can I have: output of QSG_INFO=1 plasmashell also ideally a log from massif Please reset bug status when done.
Created attachment 111788 [details] log of: QSG_INFO=1 plasmashell 2>heap.log here's the log of command: QSG_INFO=1 plasmashell 2>heap.log
Created attachment 111789 [details] massif here's the log of command: export QSG_INFO=1 pkill plasmashell; sleep 1; valgrind --tool=massif plasmashell I've made several menu switches which increase RAM usage by at least 10-30 MB.
reset bug status to confirmed
Created attachment 111790 [details] massif with some debug symbols
Leaks are in images and we're using the basic render loop - it's the same "slideshow bug" just in a different place *** This bug has been marked as a duplicate of bug 368838 ***
It might be related, but I tried the qt declarative patch on that thread and the bug still persists for me.
Oh dear. Please show me which patch you applied.
This one: diff --git a/src/quick/scenegraph/qsgrenderloop.cpp b/src/quick/scenegraph/qsgrenderloop.cpp index ca1fb9b..ebd506d 100644 --- a/src/quick/scenegraph/qsgrenderloop.cpp +++ b/src/quick/scenegraph/qsgrenderloop.cpp @@ -305,6 +305,8 @@ void QSGGuiThreadRenderLoop::hide(QQuickWindow *window) { QQuickWindowPrivate *cd = QQuickWindowPrivate::get(window); cd->fireAboutToStop(); + if (m_windows.contains(window)) + m_windows[window].updatePending = false; } void QSGGuiThreadRenderLoop::windowDestroyed(QQuickWindow *window) @@ -494,7 +496,8 @@ QImage QSGGuiThreadRenderLoop::grab(QQuickWindow *window) void QSGGuiThreadRenderLoop::maybeUpdate(QQuickWindow *window) { - if (!m_windows.contains(window)) + QQuickWindowPrivate *cd = QQuickWindowPrivate::get(window); + if (!cd->isRenderable() || !m_windows.contains(window)) return; m_windows[window].updatePending = true; -- 2.7.4
That looks like mine. Can you add debug on: lastDirtyWindow around line 395 and tell me if when it's leaking it's always evaluated to false? If so it's the same bug just my patch needs to be more extensive. If not...we have a different bug
I tried it, but the debugs in that method are not printed at all. So I think this is a different bug indeed.
If they're not being printed at all, you'd have to be running a different render loop to the one in your debug on line 3. If absolutely none of your debugs appear the other possibility is that you're not actually running the library you're compiling.
>If absolutely none of your debugs appear the other possibility is that you're not actually running the library you're compiling. I checked this by putting a debug message on the instance method, which was printed normally. > If they're not being printed at all, you'd have to be running a different render loop to the one in your debug on line 3. I'm not sure what you mean by this. How can I check if a different render loop is running and what does that mean? I'm not familiarized with c++ and qt development, so I might be missing something here.