Bug 385251 - catastrophic memory leak triggered by panel interaction
Summary: catastrophic memory leak triggered by panel interaction
Status: RESOLVED WORKSFORME
Alias: None
Product: plasmashell
Classification: Plasma
Component: Panel (show other bugs)
Version: master
Platform: Debian stable Linux
: NOR normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2017-10-01 01:35 UTC by Phil KdeBugs
Modified: 2018-10-29 02:17 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
stack trace of memory leak (7.74 KB, text/plain)
2017-10-01 01:35 UTC, Phil KdeBugs
Details
memory use, and gdb stack trace plasmashell (8.59 KB, text/plain)
2017-10-08 15:07 UTC, Phil KdeBugs
Details
a collection of callgrind reports (412.61 KB, application/pdf)
2017-10-09 03:56 UTC, Phil KdeBugs
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Phil KdeBugs 2017-10-01 01:35:44 UTC
Created attachment 108113 [details]
stack trace of memory leak

Hi,

I thought this maybe related to another problem, but some more digging suggests it is more serious. I have a workstation with 256GB of memory and so the extremely severe memory leak would probably disable most machines before time to inspect. I got a hung panel and therefore time to investigate. I disabled the "notifications" which flashes window pictures, but just clicking on an application will reproduce this - many times now.

I am running a fresh and up-to-date (30SEP2017) version of debian stretch. I am running the openbox window manager (kwin is too unstable - possible it is the panel causing this).

The relevant software (?) is:
plasma-workspace  4:5.8.6-2.1
Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19)
xserver-xorg 1:7.7+19 
 NVIDIA-SMI 375.66 
openbox 3.6.1-4
Comment 1 David Edmundson 2017-10-01 15:20:14 UTC
It's a single trace, what makes you say that it's showing a leak?

Also please include your Qt version.

Trace does show a dialog being set visible, which means presumably you were clicking on something in the panel to show a popup. Do you know what you clicked on?
Comment 2 Phil KdeBugs 2017-10-01 15:31:33 UTC
Hi,

I just installed the dbsyms for the following:

libqt5core5a-dbgsym
libqt5gui-dbgsym
libqt5gui5-dbgsym

Version: 5.7.1+dfsg-3+b1

I will try and grab a better annotated trace.
Comment 3 Phil KdeBugs 2017-10-01 15:36:02 UTC
I just noticed(!) checking 381000 how old my version seems to be , even though this is clean install of stretch. 

I'm happy to try a more recent version (if this is fixed), though it does seem quite severe...
Comment 4 Phil KdeBugs 2017-10-08 15:07:27 UTC
Created attachment 108230 [details]
memory use, and gdb stack trace plasmashell

This has the memory use (2.1G) on the first line, followed by GDB stacktrace following clicking on a firefox instance (20 panes)
Comment 5 David Edmundson 2017-10-09 01:38:42 UTC
I still don't understand. What is it a stacktrace of?

An arbitrary point in time after clicking?
Is the panel still updating when it's using all this memory?
Comment 6 Phil KdeBugs 2017-10-09 03:33:45 UTC
Hi,
OK I recompiled valgrind to make the RLIMIT 256MB (vs 8MB default) to raise the limit before we get brk errors.

I turned on the instrumentation after the start up sequence. I then took dumps before and after the perceived leak.

The attachments include: 
a) all the error output from the process
b) callgrind dumps from before (1) and after (2..7) upto 4GB of memory
c) the final stack trace from callgrind.
Comment 7 Phil KdeBugs 2017-10-09 03:56:51 UTC
Created attachment 108235 [details]
a collection of callgrind reports

Collection of callgrind before and after memory leak runaway, all the way to 4GB!!
Comment 8 Phil KdeBugs 2017-10-09 03:57:47 UTC
if you want a tar.gz of of text files I can send, but not sure how to upload so I put them in a pdf.
Comment 9 Phil KdeBugs 2017-10-09 11:56:29 UTC
to be clear - the panel completely locks up. Fortunately , alt-tab can expose a terminal to run the commands. I assumed that was obvious due to the excessive (4GB!) memory use.

Callgrind slows the execution such, I waited until after the shell get's started to get an instrumentation sample. Fortunately, plasmashell can be restarted frequently without interrupting my work...
Comment 10 Christoph Feck 2017-10-18 11:25:07 UTC
Comment #7 could provide needed information to investigate this issue.
Comment 11 Phil KdeBugs 2017-10-18 11:54:03 UTC
what extra information can I provide? It locks up, goes into a memory dive quite frequently...!
Comment 12 David Edmundson 2018-04-13 22:22:01 UTC
Callgrind doesn't show memory leaks, it shows where CPU time is spent.

massif is the useful tool here.

There is a known (now fixed) memory issue wtih Qt, when using the basic render loop. You can see this if you run QSG_INFO=1 plasmashell   if you see a line about the basic render loop it's that. If it says "threaded render loop" it's something else.
Comment 13 David Edmundson 2018-04-14 17:56:46 UTC
marking as needsinfo till then
Comment 14 Andrew Crouthamel 2018-09-28 03:31:19 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 15 Andrew Crouthamel 2018-10-29 02:17:06 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!