| Summary: | Memory leak when browsing launcher's menus | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Jesse <jessenzr> |
| Component: | Application Launcher (Kickoff) | Assignee: | David Edmundson <kde> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | bugseforuns, plasma-bugs, suse |
| Priority: | NOR | ||
| Version: | 5.12.3 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
plasmashell log
log of: QSG_INFO=1 plasmashell 2>heap.log massif massif with some debug symbols |
||
|
Description
Jesse
2018-03-31 16:42:33 UTC
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. |