Created attachment 102183 [details] Plasmashell valgrind log (~220 Mb) The plasmashell grows its memory consumption over the long periods of time. On my system plasmashell consumes ~170 Mb after boot, ~450 Mb after about a day of operation, ~900 Mb after ~2 days. In a few days without a reboot I got about 2 Gb consumed by plasmashell. I tried to track down the memory leak by running under valgrind (see its log attached), but doesn't look like a lost memory. More likely it is a growth of accounted memory. xrestop doesn't show anything interesting (it doesn't show plasmashell and the top line is KWin with ~40 Mb total memory while plasmashell consumes ~900 Mb). Kubuntu 16.10 x86_64, Nvidia drivers 370.28. I don't have fontconfig-infinality installed, but I have libfreetype6 with Infinality patches (2.7-0ubuntu0ppa5 from https://launchpad.net/~no1wantdthisname/+archive/ubuntu/ppa). I've attached my appletsrc config file to list the applets I'm using. The custom applets are: - Thermal Monitor with CPU and GPU temps: https://api.kde-look.org/p/998915 - Resources Monitor with CPU load and RAM consumption: https://api.kde-look.org/p/998908 - Netspeed Widget: https://api.kde-look.org/p/998895
Created attachment 102184 [details] appletsrc with desktop configuration
I should add that the memory leak happens even without any user activity (e.g. leaving the PC on for a night is enough for the growth to happen). No KDE notifications happen during the periods of inactivity.
Created attachment 102234 [details] Plasmashell valgrind DHAT log I've attached a log of valgrind DHAT (http://valgrind.org/docs/manual/dh-manual.html) running plasmashell for about a day. From the tool's description, the most interesting entries in the log are the ones with larger percent of program lifetime.
I tried switching to the unpatched libfreetype6 and remove the custom applets, but it didn't change anything - plasmashell still leaks memory at apparently the same rate.
I too see this same leak, after 8 days plasmashell is reported as using 10GB of "VIRT" by top, but only ~513MB of RSS. I have no swap so it's likely this is memory that has been allocated/mmap()d but never touched. I suspect this is related to (if not a dup of) "Bug 361521 - Insane virtual memory consumption and icon-cache mappings".
I'm watching memory consumption through the KDE System Monitor, the Memory column. I think it shows resident memory minus shared memory. I did not monitor virtual memory, so this bug is not about that.
(In reply to Lastique from comment #6) > I'm watching memory consumption through the KDE System Monitor, the Memory > column. I think it shows resident memory minus shared memory. I did not > monitor virtual memory, so this bug is not about that. Thanks for that pointer, with that I see "just" 439MB used. All the best, Chris
Created attachment 102500 [details] Heapprofile output (~100 Mb) I'm attaching output of heapprofile from gperftools. The plasmashell process was running for a few days with tcmalloc preloaded with LD_PRELOAD. The allocator dumped heap state every 30 minutes. You can view the logs graphically as described here: http://goog-perftools.sourceforge.net/doc/heap_profiler.html. By comparing different heap dumps you can see that there is a steady memory growth, particularly from address 0x7fad33894c49, which according to pmap output is in libGLX_nvidia.so.370.28. The logs I attached earlier also suggest that the leak has something to do with OpenGL usage.
Downgrading Nvidia driver to 367.57 does not help.
I have same problem. openSUSE Leap 42.2 plasma5-workspace 5.8.3 plasma-framework: 5.26.0 Qt; 5.6.1 Video: Intel Graphics 530
Thanks for doing that heapprofile output, it would be ideal, except for the fact you can't profile on one machine and profile on another. It tries to resolve symbols that simply won't match :S The valgrind output had one useful piece: =2222== 39,846,072 bytes in 8 blocks are possibly lost in loss record 77,372 of 77,372 ==2222== at 0x4C2CB3F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2222== by 0x22EBAC48: ??? (in /usr/lib/nvidia-370/libGLX_nvidia.so.370.28) ==2222== by 0x245CA6D6: ??? (in /usr/lib/nvidia-370/libnvidia-glcore.so.370.28) ==2222== by 0x245B7A9C: ??? (in /usr/lib/nvidia-370/libnvidia-glcore.so.370.28) ==2222== by 0x24691AA3: ??? (in /usr/lib/nvidia-370/libnvidia-glcore.so.370.28) ==2222== by 0x246933EA: ??? (in /usr/lib/nvidia-370/libnvidia-glcore.so.370.28) ==2222== by 0x2431B1B8: ??? (in /usr/lib/nvidia-370/libnvidia-glcore.so.370.28) ==2222== by 0x243250A7: ??? (in /usr/lib/nvidia-370/libnvidia-glcore.so.370.28) ==2222== by 0x2432910C: ??? (in /usr/lib/nvidia-370/libnvidia-glcore.so.370.28) ==2222== by 0x24342B86: ??? (in /usr/lib/nvidia-370/libnvidia-glcore.so.370.28) ==2222== by 0x6A464B3: glTexImage2D (qopenglfunctions.h:995) ==2222== by 0x6A464B3: QSGAtlasTexture::Atlas::bind(QSGTexture::Filtering) (qsgatlastexture.cpp:347) ==2222== by 0x6A49B42: QSGOpaqueTextureMaterialShader::updateState(QSGMaterialShader::RenderState const&, QSGMaterial*, QSGMaterial*) (qsgtexturematerial.cpp:99) ==2222== by 0x6A30101: QSGBatchRenderer::Renderer::renderMergedBatch(QSGBatchRenderer::Batch const*) (qsgbatchrenderer.cpp:2260) ==2222== by 0x6A31644: QSGBatchRenderer::Renderer::renderBatches() (qsgbatchrenderer.cpp:2503) ==2222== by 0x6A36EA4: QSGBatchRenderer::Renderer::render() (qsgbatchrenderer.cpp:2697) ==2222== by 0x6A428FE: QSGRenderer::renderScene(QSGBindable const&) (qsgrenderer.cpp:217) ==2222== by 0x6A4319A: QSGRenderer::renderScene(unsigned int) (qsgrenderer.cpp:177) ==2222== by 0x6A5355D: QSGRenderContext::renderNextFrame(QSGRenderer*, unsigned int) (qsgcontext.cpp:555) ==2222== by 0x6A9A92D: QQuickWindowPrivate::renderSceneGraph(QSize const&) (qquickwindow.cpp:424) ==2222== by 0x6A6C72E: QSGRenderThread::syncAndRender() (qsgthreadedrenderloop.cpp:623) ==2222== by 0x6A71CAB: QSGRenderThread::run() (qsgthreadedrenderloop.cpp:704) ==2222== by 0x9AE8C67: QThreadPrivate::start(void*) (qthread_unix.cpp:341) ==2222== by 0xAB76709: start_thread (pthread Which implies either we're leaking a QSGTexture somewhere. Or Qt isn't cleaning up properly. Or Nvidia isn't.
There was a significant memory leak fix in frameworks 5.35 Please let us know if that had any impact.
Since this bug report, I have upgraded to Kubuntu 17.04 (Qt 5.7.1, plasma-framework 5.31, plasma-workspace 5.9.4) and nvidia 381.22 with the rest setup mostly intact. I don't see plasmashell leak with this setup, after ~2 days of uptime plasmashell consumes ~250 Mb RAM, which is significantly less than it did before. I didn't do any long term monitoring to see if the growth still exists, but if it does, its severity is certainly reduced. Whoever fixed this, many thanks to you.
thanks for reporting back