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
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?
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.
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...
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)
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?
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.
Created attachment 108235 [details] a collection of callgrind reports Collection of callgrind before and after memory leak runaway, all the way to 4GB!!
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.
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 #7 could provide needed information to investigate this issue.
what extra information can I provide? It locks up, goes into a memory dive quite frequently...!
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.
marking as needsinfo till then
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!
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!