On an always on system, my plasmashell memory usage grows and grows. Last time i checked before restarting it, it was eating almost 900MB of ram. Reproducible: Always Steps to Reproduce: 1. measure the memory usage of plasmashell just after startup 2. use it (open apps, display notifications, move widgets, show menu, clock, calendar) 3. leave it as it was in the fresh state (close apps, close notifications restore panel position etc) 3. measure the memory usage again 4. leave it alone for some time (30 minutes?) 5. check the ram usage again Actual Results: The ram usage increased a lot. Expected Results: The ram usage to be almost back to the startup state. I attached pmap,ksysguard and /proc/$(pidof plasmashell)/status before and after usage. Where usage has been: Show the 'kickoff menu' and walk through applications send notifications show notifications show calendar hover the mouse on the taskbar items right click on the desktop to show his configuration window right click on the desktop to show the activities window move a desktop widget resize a desktop widget to the entire screen size click on the panel configuration icon show the available widgets -- Revert all of the changes so that apparently it is a newly started session Before all the described operations, Resident+shared mem was little less than 300MB After, it reached more than 630MB (!) ...and it stays that way (or still grows) till a restart.
Created attachment 101094 [details] Memory informations
I just played with nuoveau, and found that it consumes so much less memory. With a quick test (show kickoff menu, clock, panel configuration window, moving a plasmoid): nvidia blob reached 400MB nuoveau stayed at about 250MB tried nvidia 367.35 and 370.28
I forgot to add that running a compositor or not running a compositor makes 0 difference
What version of plasma-framework?
First time i tried was with framework 5.25. It persists with 5.26 qt5 is 5.7.0
@David Edmundson : Are you able to reproduce with Nvidia proprietary drivers?
New info: with raster backend, apart from having a broken desktop, it seems plasma still allows me to interact with panels, so i interacted with them by using the menu, popup some tooltips, showed the calendar and so on. Well, with export QMLSCENE_DEVICE=softwarecontext i've a ram usage that starts with 228MB and ends to 276MB Using classic opengl, doing the exact same things, it starts at 228MB and reaches 420MB.
Since it seems nouveau is not affected, I reported the very same to nvidia https://devtalk.nvidia.com/default/topic/966824/linux/huge-memory-allocation-on-plasmashell-with-proprietary-driver-nouveau-is-fine/post/4981667/?offset=5#4981701 In there, at posted a script using xdotool that did nothing else that showing the plasma configuration window; then the get wallpapers window, close both and reiterate. After 20 minutes of that, my system started swapping badly and plasma was eating almost 6GB of ram.
Oh, then it's not the issue that I fixed in 5.26 which was purely related to thumbnails. The wallpaper dialog doesn't do any custom GL, so if that's leaking only on NVidia it strongly implies the problem is higher in the stack than Plasma.
please also try with QSG_RENDER_LOOP=basic plasmashell and report on what that does
I made a 3 minute run of that xdotool script (open and close wallpaper settings multiple times). Nvidia proprietary driver + QSG_RENDER_LOOP=basic Start: 286MB End: 486MB Nvidia proprietary driver + unset QSG_RENDER_LOOP Start: 281MB End: 533MB Nouveau + unset QSG_RENDER_LOOP Start 289MB End 436MB So, in the end it seems that NVIDIA blob is using more ram, but not that much, and plasma/qt are leaking more memory just because qt uses threads with nvidia proprietary driver, right?
For what is worth, the bug is present even in plasmoidviewer. Just play with it and see how his memory usage grows with ease.
Created attachment 102436 [details] plasmoidviewer: memory maps, memory status and "valgrind --tool=memcheck --leak-check=full" log As i found that plasmoidviewer leaks memory too, i was able to make a valgrind log out of it (too slow for the whole plasmashell). See that VmRSS jumped from 392504kB to 453376kB, all i did was moving, rotate and resize it.
Created attachment 102437 [details] log with debug symbols enabled for qt5-declarative and qt5-base Same as before, but with debug symbols for (what i think) relevant libraries.
I can confirm the memory problem, though whether it's a leak or just memory not being released I don't know. Plasmashell doesn't seem to grow overnight or when the machine is idle, but any interaction with the desktop will increase plasmashell's resident memory. At start it's usually 173Mb, then depending on what I'm doing, will increase in 4-5Mb chunks or more. After just a few hours it can be as much as 400-500Mb. It will continue to grow if I let it, I've had it over a gig before, but now I usually kill plasmashell and restart it once or twice a day. System specs: KDE Plasma Version: 5.8.4 KDE Frameworks Version: 5.28.0 Qt Version: 5.7.0 Kernel Version: 4.8.10-1-ARCH Processors: 4xIntel Core i5-3470 CPU @ 3.20GHz Memory: 8 GiB Video: NVIDIA GF108 [GeForce GT 630] Driver: NVIDIA 375.20 The system is Arch with all the latest updates from the stable repos. I've tried the 'QSG_RENDER_LOOP=basic' with no effect. Tried changing rendering backends (OpenGL 3.1, 2.0 and xrender), switching to the nouveau driver, no noticeable difference. Kinfo reports almost all the used memory is held in the heap. Any other information I can add that may be helpful in tracking this down, just ask.
from 290MB to 930MB in 5 minutes: https://www.youtube.com/edit?o=U&video_id=K3nbY0xNykA
Sorry, wrong link: https://www.youtube.com/watch?v=K3nbY0xNykA
I have the same problem : the plasmashell's memory keeps growing until the system crashes. It usually takes 2 or 3 hours to fill my 8GO of RAM. I have to log out frequently to avoid the problem. System specs: KDE Plasma Version: 5.10.4 KDE Frameworks Version: 5.36.0 Qt Version: 5.9.1 Kernel Version: 4.12.3-1-ARCH Processors: 4xIntel Core i3-3120M CPU @ 2.50GHz Memory: 7.7 GiB
*** This bug has been marked as a duplicate of bug 381000 ***
I'm sorry, but how can this be a duplicate of bug 381000? * My wallpaper is static, i've just one image * I reported this bug on 2016-09-15, while 381000 is from 2017-06-09 and seems to be caused by a commit done *after* i reported this. (What is wrong is comment 18, which probably is referring to 381000.) If the source cause is the same, i'd be happy to be wrong!
I have also a static background but ... I had a photo widget on my desktop, configured as ... slideshow ! I've shut it and it works fine.
Yes, by static i mean not slideshow :P
I`m on plasma 5.11.1 and when I open "plasma discover" memory usage goes from 450MB to 7.8GB/8GB, eventually filling up my swap too rendering my system non-responsive. RAM usage keeps on increasing until I find some way to close the plasma discover.
*** Bug 388580 has been marked as a duplicate of this bug. ***
Marking as Major since slideshow options are pretty popular and present a large surface area for user dissatisfaction when they eat up too much RAM and bog down the system.
I'm not sure if Bug 388580 is a duplicate or not; I have only started noticing problems recently, and I'm using the radeon driver. (Random data point: immediately after start-up, plasmashell was 4G/400M (virt/res), and is up to 6G/2G after about 8 hours.)
I have the same problem using the following versions: KDE Plasma: 5.11.4 KDE Frameworks: 5.41.0 Qt: 5.9.3 Kernel: 4.12.12-gentoo I'm using the nouveau driver, so I doubt it is driver related. In order to test if this is background image related, I watched the memory used by plasmashell while cycling through background images using the context menu option. Every time I change the image I can see a large increase in RSS. For me this issue is fairly new. I can't pin it down exactly, but I would think it must be related to my last update, which included the updates to frameworks 5.41 from 5.40 and Qt 5.9.3 from 5.7.x (not sure what exact version I used previously).
I can still confirm that this Bug exsists on actual KDE Neon. Changing to slideshow increases CPU-Usage immediatley, going back to single image und restart plasmashell solves the problem. The same happends on Archlinux.
It happens on Kubuntu 17.10 . I see plasmasheel eating all RAM of my system (16GiB or total RAM).
Also, I noticed that screenlock could hang if is using slideshow wallpaper
I am experiencing this bug on a single monitor with the AMDGPU driver, Qt 5.9.3, and Plasma 5.11.4, running on Linux 4.14.13-gentoo. This bug has been affecting me for a few months now, plausibly since I upgraded to the Qt 5.9.x series from 5.7.1 at the end of September 2017. I have the slideshow wallpaper set to change every 29 minutes and 1 second, and I can get 1-2 weeks of use out of my desktop session until I run out of available memory and my system starts thrashing and I have to take steps (see below) to recover and continue. Memory usage seems to grow even while I am away from my computer (i.e., while it's sitting at the KDE Screen Locker with the monitor powered down). Of particular interest on my system: the majority of the memory usage isn't attributed to the plasmashell process, as reported by 'ps' and 'top'. Bizarrely, the memory usage appears to be accountable to *no process*. Because of this, it took me a long time to track it down to Plasma. I even reported a kernel bug[1], as the memory seemed to be inexplicably in use by the kernel itself: adding up the memory counters in /proc/*/status across all running processes yields a total memory usage that does not account for the complete exhaustion of MemAvailable in /proc/meminfo. How I know plasmashell is the culprit: 1. My system started to become sluggish, which happens as the kernel starts evicting pages of executable code from RAM and having to load them back in from disk. (If not immediately addressed, this condition worsens until I have no choice but to invoke the OOM killer using Magic SysRq to reclaim a little bit of memory so I can proceed with the next steps.) 2. I switched to a text-mode VT and ran 'echo 2 > /proc/sys/vm/drop_caches' as root. This elicited a short pause before the prompt reappeared, and then 'free' reported a small amount of additional available memory. 3. I killed (by SIGTERM) my plasmashell process. Some memory was immediately freed (as expected), but about 3 GB was still unaccounted for. That is, 'free' reported much more memory as "used" than the sum of all processes in my system. 4. I ran 'echo 2 > /proc/sys/vm/drop_caches' again. This time the prompt took noticeably longer to reappear. 5. Now 'free' reported a sane number for "used", which was fully attributable to the set of remaining processes running on my system. My usual procedure for recovering from the low-memory scenario is to log out of my KDE session entirely and then do the drop_caches trick to get the kernel to release the apparently unaccounted-for memory. But this time I left my session running and only killed plasmashell. That was enough to unstick the memory, and that's how I found my way to this bug report. I am a low-level C/C++ developer, but I have very little experience with OpenGL and no experience with Qt. My current (only somewhat informed) working theory is that the plasmashell process is allocating wallpapers in video memory but never freeing them and that this memory is not accounted to the process in the usual ways, as it is nominally not system RAM. However, because VRAM is limited, eventually the kernel shifts the disused wallpapers out of VRAM and into system RAM, where they sit, not accounted to any process. I do not understand why killing the plasmashell process does not immediately cause the kernel to free this memory, though. I have to tell the kernel to drop its inode+dentry caches to get the memory back. As I only get into this situation every week or two and have to address the situation immediately when it occurs, it's hard for me to try things and report back quickly, but I would gladly welcome any suggestions and will supply any information requested. Since I run Gentoo, I am able to patch sources and rebuild packages easily. At the moment, I am going to try disabling the slideshow wallpaper and see if plasmashell no longer causes this unaccountable memory usage. I will report back in a few weeks with my findings. __________ [1] https://bugzilla.kernel.org/show_bug.cgi?id=197783 - Incidentally, the rogue memory pages are swappable.
Thanks a lot for the investigation and analysis, Matt! If you do happen to pinpoint the issue, you're welcome to submit a patch using http://phabricator.kde.org/. More information is available at https://community.kde.org/Get_Involved/development. If you need a hand with anything, don't hesitate to let me know.
I'm also affected by this bug in the PC at home, but not at work, both updated to plasmashell 5.11.5, kde 5.41.0, Kubuntu 17.10 This weekend I experimented a bit at home: when I changed the second monitor desktop from "Slideshow" (20 secs between image change) to "Hunyango" the bug stopped. When I restored back to "Slideshow" the bug reappered. "free" shows that a lot of memory is used in "shared"
So this whole thing has got quite messy. There was this bug: https://bugreports.qt.io/browse/QTBUG-61754 This as reported I'm 99% sure is fixed. We've also got a bug about high CPU, to do with stopped animation drivers not getting removed. If you're running < Qt5.10 or < 5.9.3 upgrade now so you have them and don't confuse this report. Please also report if you're using the basic or threaded render loop. You can find out by running QSG_INFO=1 plasmashell and reading the output. Something like: "10:19:03.848 qt.scenegraph.general: QSGRenderLoop::instance threaded render" narrow that down and it'll help. Also please download the sample QML file in https://bugreports.qt.io/browse/QTBUG-61754 and report on whether that gives you issues.
I repeat, the bug i reported (this one) was not about wallpaper/images photo widgets and so on. if the underlying cause is the same, i don't know.
Created attachment 110735 [details] time-series chart demonstrating plasmashell memory leak Do we need to open a new bug report for the slideshow wallpaper issue? I am running Qt 5.9.4 and Plasma 5.12.1 now, and it most definitely is still an issue. Please see the attached chart, which visualizes the output of... • free | grep '^Mem:' • grep '^VmRSS:' /proc/"$(pgrep plasmashell)"/status ...with samples taken at 1-second intervals while manipulating plasmashell. Particularly noteworthy is that the actual plasmashell process's VmRSS hardly changed the whole time. The system is evidently not accounting the memory usage to the plasmashell process. Nevertheless, given enough time, plasmashell brings the system to its knees. (I actually had to use AltGr+SysRq+F to manually invoke the OOM killer just so I could terminate plasmashell, as my session had become unresponsive.) I would reasonably expect to see the gradually increasing "Buff/Cache" line and the gradually decreasing "Free" line, as the block cache should be caching the JPEG files as they are loaded from disk. (This is no problem, although frankly plasmashell ought to be calling posix_fadvise(2) with POSIX_FADV_DONTNEED on these files.) What I would NOT expect to see is the "Used" line increasing and the "Available" line decreasing. This suggests that memory is being consumed by something other than the block cache. My best guess is that plasmashell is not properly disposing of its textures. It takes a while for them to fill up VRAM, but then they start spilling into system RAM. I could test this hypothesis if I knew how to view how much VRAM is used/free.
Please see my requests on #34
(In reply to David Edmundson from comment #37) > Please see my requests on #34 (In reply to David Edmundson from comment #34) > If you're running < Qt5.10 or < 5.9.3 upgrade now so you have them and don't > confuse this report. (Quoting myself from comment #36) > I am running Qt 5.9.4 and Plasma 5.12.1 now > Please also report if you're using the basic or threaded render loop. You > can find out by running QSG_INFO=1 plasmashell and reading the output. qt.scenegraph.general: QSG: basic render loop qt.scenegraph.general: Using sg animation driver qt.scenegraph.general: texture atlas dimensions: 4096x2048 qt.scenegraph.general: R/G/B/A Buffers: 8 8 8 8 qt.scenegraph.general: Depth Buffer: 24 qt.scenegraph.general: Stencil Buffer: 8 qt.scenegraph.general: Samples: -1 qt.scenegraph.general: GL_VENDOR: X.Org qt.scenegraph.general: GL_RENDERER: AMD Radeon (TM) R7 300 Series (BONAIRE / DRM 3.23.0 / 4.15.3-gentoo, LLVM 5.0.1) qt.scenegraph.general: GL_VERSION: 3.0 Mesa 17.3.3 qt.scenegraph.general: GL_EXTENSIONS: *(snip)* qt.scenegraph.general: Max Texture Size: 16384 qt.scenegraph.general: Debug context: false > Also please download the sample QML file in > https://bugreports.qt.io/browse/QTBUG-61754 and report on whether that gives > you issues. I observed no issues when I ran the sample QML file in qmlscene, but those sample images are tiny and would take a very long time to fill up VRAM, so it may not be a useful test.
Me, the OP, reported the issue on QT 5.7.x times, so the bug here: https://bugreports.qt.io/browse/QTBUG-61754 does not apply at all. Is there any chance to bring the title of this back to the original, the 'thread' has derailed... It originally was: "[plasmashell] [Bug 368838] plasmashell keeps eating ram (NVIDIA BLOB), but never release it." The "NVIDIA BLOB" part is irrelevant.
Sorry your bug report has been "derailed," Antonio, though it's very possible that the symptoms we're each observing may have the same root cause. I just installed radeontop and watched my card's VRAM usage climb rapidly while running the slideshow wallpaper in plasmashell. Stopping the slideshow did not release the VRAM. Killing plasmashell did.
The memory leak also occurs while displaying application's icons. Displaying application's icons in the launcher constantly increases plasma's memory usage. Steps to reproduce. 1. Display application's icon (application menu, application launcher and application dashboard trigger the memory leak) Bear in mind since icons are low size files the memory leak per icon is quite low, the problem becomes evident while displaying a lot of icons over time, that's why you have to rapidly navigate the menus due to time constrains, normal use would take a couple of days. The problem is that there is no workaround since application's icons are always present and can't be disabled.
That Qt bug was reportedly fixed in 5.9.2. If that's the cause, then anyone using a later Qt version should be fine. Is there anyone using Qt 5.9.2 or beyond who can reproduce this issue?
(In reply to Nate Graham from comment #42) > Is there anyone using Qt 5.9.2 or beyond who can reproduce this issue? As I mentioned in comment #36 and comment #38, I am running Qt 5.9.4, and I can still easily exhaust all system memory by running a slideshow wallpaper in plasmashell. I don't know about the application icons thing. I do recall that I used to see the plasmashell process taking hundreds of megabytes of RAM and sometimes even over a gigabyte. I haven't observed that in a while. Nowadays its major memory leak appears to be in VRAM.
My current system is QT 5.10.0 and Plasma 5.12.1. The "memory leak" error is still present, since version QT 5.9.1 If I activate the slideshow in the picture frame applet, I miss about 150 MB of memory after every picture change, which is no longer released.
qt5 5.10.0 here. Memory increases over time as described in the first post, nothing changed.
I am also still seeing the issue with Qt 5.9.4, plasma 5.11.5 (full list of my current packages posted to Bug 388580 so as not to clutter this report).
*** Bug 387341 has been marked as a duplicate of this bug. ***
Moving discussion here from my bug report at 388580… Summary of my findings form that other thread (Radeon R9 M280X, Linux 5.9 – 5.15, Mesa any version, Qt 5.9.3): 1. The issue doesn't occur with the "AMD GPU Pro" userland GL stack (in return you get s***loads of other issues) – only MESA (including ancient versions) is affected 2. Memory usage of the offending process will be accounted correctly with running it with `LIBGL_ALWAYS_SOFTWARE=true`, but the leaking issue will persist 3. The leak can be greatly accelerated by enabling the "Media-Frame" Plasmoid 4. I am absolutely not able to compile a working Qt + KDE stack to bisect this issue 5. (Setting `QSL_RENDER_LOOP=threaded` seems to make the issue go away ← Still investigating this currently!) @Matt Whitlock > Have you tried running radeontop? `radeontop` doesn't work on my system (Debian unstable with current 4.15.0 kernel): amdgpu DRM driver is used, but amdgpu VRAM size reporting is not enabled amdgpu DRM driver is used, but amdgpu VRAM usage reporting is not enabled Failed to get VRAM usage, kernel likely too old Do you think there are any insights to be gained by compiling a custom kernel for this? One other thing I noticed (not sure if its related to this issue) is that when enabling DisplayCore (DC) for the `amdgpu` driver (kernel flag `amdgpu.dc=1`), I get lots of these messages in `dmesg`: swiotlb: coherent allocation failed for device 0000:00:01.0 size=2097152 CPU: 0 PID: 9635 Comm: kworker/u8:15 Tainted: G O 4.15.0-1-amd64 #1 Debian 4.15.4-1 Hardware name: LENOVO 80NY/Allsparks 5B, BIOS CECN43WW 09/15/2015 + A long stack trace with calls such as: `amdgpu_gem_object_create`, `ttm_tt_bind` and `swiotlb_alloc_coherent` (i.e.: memory related) This may be related to the accounting issues…
Hmm… At least for me there seems to be a pretty obvious corrolation here: QSG_RENDER_LOOP=basic → Memory leak QSG_RENDER_LOOP=threaded → No issues, no leaking Can other people confirm this (both with MESA and with other/propritary GL libraries)?
can this be tried again with a more recent Qt? either the latest 5.9 or 5.10 making sure both of these patches are in: https://codereview.qt-project.org/#/c/200715/ https://codereview.qt-project.org/#/c/202781/
QSG_RENDER_LOOP=threaded solves the problem here. Graphics: Card-1: Intel 2nd Generation Core Processor Family Integrated Graphics Controller Card-2: NVIDIA GF117M [GeForce 610M/710M/810M/820M / GT 620M/625M/630M/720M] Display Server: x11 (X.Org 1.19.6 ) driver: intel Resolution: 1366x768@60.05hz OpenGL: renderer: Mesa DRI Intel Sandybridge Mobile version: 3.3 Mesa 17.3.5
Plasma 5.12.1 QT 5.10.1
QSG_RENDER_LOOP makes no difference to me (i'm not testing media frame widgets or slideshow wallpaper, see first post).
@Marco Martin: I've tested with the [Qt binary 5.9.4 binary release](https://download.qt.io/official_releases/qt/5.9/5.9.4/) by setting the correct `PATH`, `LD_LIBRARY_PATH`, `QML2_IMPORT_PATH` & `QT_PLUGIN_PATH` and starting the system `plasmashell` binary with `QCG_RENDER_LOOP=basic`. I'm happy to report that there was no apparent memory leaking over the course of over an hour. 😃
(In reply to Alexander Schlarb from comment #54) > `QCG_RENDER_LOOP=basic`. It's supposed to be QSG_RENDER_LOOP. ("SG" for "scene graph.")
That's a typo, the actual command had been issued with `QSG_RENDER_LOOP=basic`.
(In reply to Marco Martin from comment #50) > can this be tried again with a more recent Qt? either the latest 5.9 or 5.10 > making sure both of these patches are in: > > https://codereview.qt-project.org/#/c/200715/ > https://codereview.qt-project.org/#/c/202781/ The second patch set (202781) is a reversion of the first patch set (200715) plus one extra line [sgrc->endSync();]. I confirm that the dev-qt/qtdeclarative-5.9.4 that is built on my Gentoo system does contain that added line. (In reply to Alexander Schlarb from comment #48) > 2. Memory usage of the offending process will be accounted correctly with > running it with `LIBGL_ALWAYS_SOFTWARE=true`, but the leaking issue will > persist I tried this and do confirm that the leak persists and is accounted to the plasmashell process. In this case, radeontop shows unchanging VRAM usage, which is not surprising, given that the rendering is happening all in software. (The transitions between wallpaper images are a lot jerkier, and CPU usage is through the roof.) It's worth noting that triggering this bug is not always so simple as starting up a plasmashell and running a slideshow. For me, it can take many minutes of running an aggressive slideshow before plasmashell starts to leak memory. Maybe this suggests that a race condition is the initial triggering event that leads into the state in which plasmashell leaks textures. Also, I'm not sure if this is a placebo effect, but it may be that mousing over the launcher icons and task manager buttons in the panel (to cause the sliding tooltips effect) may increase the likelihood of starting the memory leak. Once it starts leaking, it's dramatic and fast when you're running a slideshow wallpaper with a 1-second interval. (In reply to gertlink_nospam from comment #51) > QSG_RENDER_LOOP=threaded solves the problem here. After about 10 minutes of trying, I have been unable to trigger the leak when running plasmashell with the threaded render loop. I'll leave the slideshow wallpaper enabled (with a less aggressive, 29-minute interval), using this threaded render loop, and I'll continue to monitor for excessive VRAM usage.
Holy cow that worked! (pkill plasmashell; QSG_RENDER_LOOP=threaded kstart plasmashell) Now my system is running smooth as f*! :D Even closing opened applications returns my total system memory usage back to a mere 678 KB! I've been experiencing this problem since the upgrade from KDE Neon 5.8 LTS to 5.12 LTS. It might not be relevant, but my theme has lots of semi-transparent elements and my background changes every 30 seconds. I could not survive an hour before even my swap ran out. A movie would hang 30 minutes in. For the time being, I have modified file /etc/xdg/autostart/org.kde.plasmashell.desktop to contain: Exec=QSG_RENDER_LOOP=threaded plasmashell --shut-up And deleted file /etc/xdg/autostart/plasmashell.desktop since it was an almost exact duplicate, the only difference being that it included the "--shut-up" parameter of which I can't find any documentation but is mentioned a lot with "100% CPU usaged".
I'm glad you guys found a workaround for your particular case. However, mine (see first post), is still present. I just made a video showing how plasma can reach about 1GB of ram usage from 300MB in a bunch of seconds. Something is better than what i observed in comment #16 and #17, but leaks are still present. see: https://www.youtube.com/watch?v=DviiWnq2Rp8
(In reply to Antonio Orefice from comment #59) > I just made a video showing how plasma can reach about 1GB of ram usage from > 300MB in a bunch of seconds. I too can reproduce a rather serious memory leak just by scrolling the "Add Widget" panel up and down repeatedly, as you demonstrated in your video. This seems to be a separate issue from the scene graph basic render loop texture leak. This one doesn't cause VRAM usage to increase but rather causes the plasmashell process's VmRSS to increase.
Exactly. Exactly what i reported when i opened this bug, see comment #1. I don't want to be harsh, but this 'bug report' is becoming a mess since it has been arbitrarily joined/defaced with something unrelated.
@Antonio Orefice: Sorry 'bout that. There seemed to be a connection between these two issues that apparently isn't there. Since the QSG issue has fixed in Qt 5.9.4 and 5.10.0, I nominate that we close 387341 (that is about a VRAM memory leak with QSG_RENDER_LOOP=basic and MESA drivers, as we now know) as resolved upstream and return the discussion of this thread to the RSS memory leak with the nVidia binary drivers. I cannot, btw, reproduce your issue: There is a short increase in memory usage when attempting any of the actions in the video, but the memory is free'd quickly again.
(In reply to Alexander Schlarb from comment #62) > the RSS memory leak with the nVidia binary > drivers. Um, I'm using the open-source AMDGPU driver, and I can easily drive up plasmashell's VmRss by doing what Antonio did in his demo video.
I feel like an idiot. I just tried running plasmashell with qt 5.9.4 “again” and found that it crashes on startup. Looking through my command-history it seems that all the search paths were slightly wrong *facepalm*. Just forget everything I said about QSG_RENDER_LOOP=basic working in newer Qt…
*** Bug 390238 has been marked as a duplicate of this bug. ***
*** Bug 390436 has been marked as a duplicate of this bug. ***
*** Bug 391377 has been marked as a duplicate of this bug. ***
There's a branch of plasmashell davidedmundson/wallpaperrewrite Could someone reliably with this bug build and try it please. It's not written to specifically fix anything, there is no bug in plasma-side code, but it does remove a lot of the complex intertwining of image loading and animation scripts that we previously had.
(In reply to David Edmundson from comment #68) > There's a branch of plasmashell davidedmundson/wallpaperrewrite > > Could someone reliably with this bug build and try it please. > > It's not written to specifically fix anything, there is no bug in > plasma-side code, but it does remove a lot of the complex intertwining of > image loading and animation scripts that we previously had. I can still reproduce this bug with that branch. While the rate at which the memory usage increases is silghtly slower, the memory usage still increases to around 600 to 700 MiB quickly. I have tested with both the media frame and slideshow wallpaper (this was the one which showed the slower increase with your branch). The memory leak is still present in both cases (I tested with the image set to change at 3 sec intervals). Unrelated to this issue, the option to blur the part not covered by the wallpaper when it is 'centered' seems to be broken in your branch. The blur is applied to the entire background, instead.
Not too surprising. Thanks for reporting back.
*** Bug 392174 has been marked as a duplicate of this bug. ***
So the consensus is that QSG_RENDER_LOOP=threaded doesn't fix the issue? It seems like the discussion of this issue should take place in a Qt bug report, since it's not a KDE issue. https://bugreports.qt.io/browse/QTBUG-61754 has been closed as fixed; do we need to file a new bug or re-open that one?
(In reply to Nate Graham from comment #72) > So the consensus is that QSG_RENDER_LOOP=threaded doesn't fix the issue? There are two issues. QSG_RENDER_LOOP=threaded *does* avoid the VRAM memory leak but *does not* avoid the in-process memory leak.
(In reply to Matt Whitlock from comment #73) > There are two issues. QSG_RENDER_LOOP=threaded *does* avoid the VRAM memory > leak Thanks Matt. So should Qt use the threaded render loop by default, then? Or should we? Or something else? > but *does not* avoid the in-process memory leak. So perhaps we need a Qt bug to track this. Was https://bugreports.qt.io/browse/QTBUG-61754 tracking that such that it should be re-opened, or do we need a new one?
*** Bug 392181 has been marked as a duplicate of this bug. ***
(In reply to Nate Graham from comment #74) > So should Qt use the threaded render loop by default, then? Or > should we? Or something else? Presumably the VRAM memory leak in the basic render loop should be found and fixed. I would stop short of suggesting that plasmashell switch to the threaded render loop by default in the meantime, as I do not know whether the threaded render loop has drawbacks. > So perhaps we need a Qt bug to track this. Was > https://bugreports.qt.io/browse/QTBUG-61754 tracking that such that it > should be re-opened, or do we need a new one? I do not know the cause of the in-process memory leak. It may be that QTBUG-61754 is not really fixed, or it may be a fault in plasmashell, or it may be something else.
Please just keep in mind that the current first-use experience is absolutely abysimal for everybody using the described configuration: You log into an up-to-date system with plasmashell and everything will appear to work fine. A few minutes/hours (depending on configuration) your system will inexplicietly become slow and finally either your KDE desktop or (more likely) your entire system will crash/hang. This will happen every time you use KDE, but not on whatever DE/OS you came from and there won't be any obvious reason. Likely you won't be using KDE for a long time after having such an experience a couple of times. (The people here bothering to dig up such a hard to grasp issue are the absolute minority, please don't forget that.) Yes, I'm very much advocating that `QSG_RENDER_LOOP=threaded` be made default at least on Desktop MESA platforms. > Presumably the VRAM memory leak in the basic render loop should be found and fixed. Is Qt actively working on that? Or will they just stand by on this issue “'cause the threaded one is better anyways”? I guess what I'm asking is this (and absolutely correct me if I got a wrong impression of the situation!): Is there anything important that Qt needs QSG_RENDER_LOOP=basic for, that QSG_RENDER_LOOP=threaded cannot do? Because presumably the basic loop was originally written first and then threaded got added for getting some extra performance at the cost of complexity, so it was decided to only enable it on (GL) platforms known to be “good”. So, assuming that my assumption on how this developed is correct, I'm asking you if there is any reason for them (or anybody) to keep the basic render loop in good shape, when the threaded one gets the job done anyway on all platforms they consider important and their long run goal is phase out usage of the basic loop anyways?
We're all aware of the issue's implications, and are trying to fix it. I'm also wondering if there's any disadvantage to always using the threaded render loop. Alexander, would you be able to run with it for a while and report any regressions, if any?
> So should Qt use the threaded render loop by default, then? Or should we? Or something else? Is decided by Qt based on your graphic card/drivers. Maybe that selection code in Qt can be tweaked, but we most definitely shouldn't force it from our side. Especially not this way round (forcing basic would be maybe ok). If you do this on a driver that doesn't support threaded GL you're going to have random crashes at any point.
Basically, we need to find a path forward here. This bug is getting pretty long and squirrelly, especialyl considering that it's not our fault. Do we need a few more Qt bugs, David?
@Nate Graham: > I'm also wondering if there's any disadvantage to always using the threaded render loop. Alexander, would you be able to run with it for a while and report any regressions, if any? I've been running my entire KDE Desktop session with `QSG_RENDER_LOOP=threaded` set in `.pam_environment` for the last month and it only had an effect on Plasma's (invisible) memory usage. Everything else is working as before (i.e.: KWin still has its share of issues –particularily on Wayland – but it's not worse than before either). As a matter of fact with this bug it's so bad I wouldn't be using Plasma at all (like I did for 2 months before finding this solution) if the issue wouldn't have been fully resolved by this. @David Edmundson: > Is decided by Qt based on your graphic card/drivers. I did some digging in the Qt source code on why this is disabled and it mostly seems to be because of a bug in an old (pre-2014) version of `libxcb` that caused issues for MESA. I filled a bug with Qt to suggest reevaluating that blacklist entry – we'll see what they say: https://bugreports.qt.io/browse/QTBUG-67277 > Maybe that selection code in Qt can be tweaked, but we most definitely shouldn't force it from our side. If Qt decides that it's safe to remove that blacklist entry for 5.11+ or maybe just 5.12+, then forcing this from Plasmashell's side for older should IMHO be considered (with an appropriate version guard and comment so that's its easy to remove once support for these versions is dropped of course).
fredag den 23. marts 2018 14.38.09 CEST skrev du: > https://bugs.kde.org/show_bug.cgi?id=368838 > > --- Comment #81 from Alexander Schlarb <alexander-kde@ninetailed.ninja> --- > > @Nate Graham: > > I'm also wondering if there's any disadvantage to always using the > > threaded render loop. Alexander, would you be able to run with it for a > > while and report any regressions, if any? > I've been running my entire KDE Desktop session with > `QSG_RENDER_LOOP=threaded` set in `.pam_environment` for the last month and > it only had an effect on Plasma's (invisible) memory usage. Everything else > is working as before (i.e.: KWin still has its share of issues > –particularily on Wayland – but it's not worse than before either). Thanks for the tip, I'm trying that, so far witout any problems :) --- Kindly, Anders
*** Bug 391063 has been marked as a duplicate of this bug. ***
Now managed to reproduce locally...but not even slightly consistently. Can someone who has it reliably check if reverting eeb320bbd8763f3e72f79369cc3908e999a0da3c in QtDeclarative fixes it. My theory from some other user's output in 381000 was that we have a situation in plasma where Qt's basic loop always things some other window needs updates and we never hit endSync which releases the textures; but then that theory was drowned in confusion from people talking about other bugs and it got lost.
Lucky timing, just gave up and hit submit. Had diff --git a/src/quick/scenegraph/qsgrenderloop.cpp b/src/quick/scenegraph/qsgrenderloop.cpp index ca1fb9ba5..a8beac369 100644 --- a/src/quick/scenegraph/qsgrenderloop.cpp +++ b/src/quick/scenegraph/qsgrenderloop.cpp @@ -418,6 +418,8 @@ void QSGGuiThreadRenderLoop::renderWindow(QQuickWindow *window) emit window->afterAnimating(); cd->syncSceneGraph(); + + qDebug() << "maybe ending sync" << lastDirtyWindow; if (lastDirtyWindow) rc->endSync(); all the while not leaking this was printing with true on the end...then randomly just as I started doing something else I'm seeing this always false.. and it's clear from the code that at that point it stops releasing anything. If we find the cause of that, we'll get this fixed.
Steps to reproduce: - set to QSG_RENDER_LOOP=basic - create a slideshow - open a taskmanager tooltip - then we leak Tooltip is not rendered because it's not visible. But it's re-used so still exists. QSGGuiThreadRenderLoop::renderWindow() returns false for that window without doing anything. But it's still marked as updatePending, so we never think we've rendered all the windows. This patch in Qt will fix it; though arugably isn't quite at the right cause. diff --git a/src/quick/scenegraph/qsgrenderloop.cpp b/src/quick/scenegraph/qsgrenderloop.cpp index ca1fb9ba5..51b4775f2 100644 --- a/src/quick/scenegraph/qsgrenderloop.cpp +++ b/src/quick/scenegraph/qsgrenderloop.cpp @@ -384,7 +384,8 @@ void QSGGuiThreadRenderLoop::renderWindow(QQuickWindow *window) bool lastDirtyWindow = true; auto i = m_windows.constBegin(); while (i != m_windows.constEnd()) { - if (i.value().updatePending) { + QQuickWindowPrivate *cd = QQuickWindowPrivate::get(i.key()); + if (i.value().updatePending && cd->isRenderable()) { lastDirtyWindow = false; break; }
Hi, I have memory leak that occurs without having the slide-show but all other bugs on memory leak seem to be linked to this one so I'm posting here. Since updating to plasma 5.12.x on neon LTS, a memory leak started to appear on plasmashell. This is not happening on my other machine on neon user and both desktop have same config (same background, widgets, etc.). Main difference between the two is QT 5.9.3 on neon LTS whereas QT 5.10 on neon user. So I feel this is a different issue to the one reported here, and probably fixed by QT 5.10 and so ideally should be reported as an inconsistency in the update to plasma 5.12 in neon LTS...but I don't know where to report this .
(In reply to Gauthier from comment #87) > Hi, > > I have memory leak that occurs without having the slide-show > So I feel this is a different issue to the one reported here Please don't report unrelated issues in a pre-existing bug report; file a new one instead. See https://community.kde.org/Get_Involved/Bug_Reporting#One_issue_per_bug_report Also, if the issue is already resolved in a later Qt version, there is no need to report a bug at all.
Please test: https://codereview.qt-project.org/#/c/224684/
Setup: dev-qt/qtdeclarative-5.9.4 kde-plasma/plasma-desktop-5.12.3 QSG_RENDER_LOOP unchanged OpenGL vendor string: X.Org OpenGL renderer string: AMD CAYMAN (DRM 2.50.0 / 4.15.4-gentoo, LLVM 5.0.1) OpenGL core profile version string: 4.3 (Core Profile) Mesa 18.0.0 Before applying your patch a 1s interval slideshow while playing around with plasma reproducibly led to a mem increase of rougly 50-100MB/s. After applying the patch and restarting plasma => mem consumption looks stable for over an hour now. You sir, deserve a medal!
*** Bug 392599 has been marked as a duplicate of this bug. ***
*** Bug 392568 has been marked as a duplicate of this bug. ***
*** Bug 392524 has been marked as a duplicate of this bug. ***
FYI. Merged now into Qt 5.11.0. Due to be released in a few months
I tried the patch but the memory leak bug reported in #392568, which was marked as a duplicated of this one, still persists for me. So either I'm missing something or that bug is not really a duplicated.
*** Bug 392668 has been marked as a duplicate of this bug. ***
(In reply to Jesse from comment #95) > I tried the patch but the memory leak bug reported in #392568, which was > marked as a duplicated of this one, still persists for me. So either I'm > missing something or that bug is not really a duplicated. My bug 392668 which was also marked duplicate will likely also persist, but we will have to see.
*** Bug 393248 has been marked as a duplicate of this bug. ***
how do I go about changing "QSG_RENDER_LOOP" to threaded? FYI, when I run from a terminal "QSG_INFO=1 plasmashell" I get nothing back.
(In reply to David Edmundson from comment #89) > Please test: https://codereview.qt-project.org/#/c/224684/ David, do will your patch be in QT 5.10?
Qt 5.10 is closed now, so it will be in Qt 5.11. Ask your distros to backport it (as Kubuntu already has into the Qt 5.9.5 they'll ship with Kubuntu 18.04: https://bugs.launchpad.net/ubuntu-rtm/+source/qtdeclarative-opensource-src/+bug/1761016).
KDE 5.12.4, Frameworks 5.45.0, Qt 5.10.1. When using the slide-show memory is filling up pretty fast.
See my previous comment: this has been fixed in *Qt 5.11*. Ask your distros to backport the patch to their Qt 5.9.x and 5.10.x packages.
Nate, David, will the fix be backported to KDE Neon? I'm asking here since Neon is the showcase of KDE software. Thanks!
*** Bug 377795 has been marked as a duplicate of this bug. ***
Thought to give an update. I'm using Kubuntu 18.04. The original issue reported here by Antonio seems fixed. Video here: https://vimeo.com/270079798 The memory leak due to wallpaper changes isn't. Video here: https://vimeo.com/270080920
>Nate, David, will the fix be backported to KDE Neon? I don't deal with any downstreams. You'll have to ask them. As for your video, Qt 5.11 isn't out yet, are you sure Kubuntu has it?
(In reply to David Edmundson from comment #107) > As for your video, Qt 5.11 isn't out yet, are you sure Kubuntu has it? Kubuntu has Qt 5.9.5, with a backport of your fix as stated here: https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1761016 But Nate is best able to answer your question.
The bug was not that plasmashell uses memory, but rather that the usage grew infinitely and the memory was never released. In Kubuntu 18.04, I'm happily using a slideshow wallpaper and yes, while plasmashell consumes memory in the process, the memory usage doesn't grow infinitely and it doesn't hold onto that memory forever like it used to.
(In reply to Nate Graham from comment #109) I hate to be the "bad news" guy, but this looks exactly like what you describe - an ever growing, never-releasing memory problem. Here is a slideshow video: https://vimeo.com/270145715 The rate of increase seems lower than before the fix, but it's there. With the 4k pics it looks like about 30MB per image switch. Try going from 3seconds to 2seconds or vice-versa. Changing the interval at least once seems to matter. Three of the 4k pictures are approx. 1.5MB, the eagle is 350KB, the blue desert is 900KB, the mountain valley is 2.7 MB. The Ubuntu ones were in the 500KB vicinity. The problem is not as apparent with small image files. P.S. A few tests later, plasmashell is at 4.4GB resident memory.
(In reply to Ovidiu Chi from comment #110) Plasmashell *does* still have a memory leak, but it's not the one from this bug. Actually, it *is* the one from the original report in Comment #0, but this thread morphed into being about the other leak, which has been fixed. The original, in-process (non-VRAM) memory leak still exists and can be triggered by making plasmashell repaint a lot of images, such as by aggressively scrolling the list of available widgets.
@Ovidiu, A packager stating something doesn't necessarily mean much. Can you point me to the packaging code. Also do you have https://codereview.qt-project.org/#/c/202781/ which is for a different leak. @Matt How can you tell what is leaking from looking at comment #0? and what do you mean by an "in-process leak". All leaks are in-process.
(In reply to David Edmundson from comment #112) > @Matt > How can you tell what is leaking from looking at comment #0? There have been at least two distinct memory leaks discussed in this thread. The original report by Antonio Orefice is about a memory leak that occurs when Plasma renders images. Antonio posted a link to a video demonstrating the leak in Comment #59. I am able to reproduce his leak by the same method: force Plasma to paint a lot of images in a short amount of time. It will also leak just the same eventually in normal use, but it takes longer. The leak occurs even without opening the "Add Widget" panel and scrolling the list up and down like mad, but that's one quick way to reproduce it. The other leak was due to the logic error that you described in Comment #86. That leak has been fixed by https://codereview.qt-project.org/#/c/202781/. > and what do you mean by an "in-process leak". All leaks are in-process. Firstly, that's not true; it's entirely possible to leak pixmaps, and those are in the X server's process, not the X client's. But in this case, what I meant was that the leak that was fixed by calling endSync() was a leak of graphics memory, not a leak of system memory, so it wasn't accounted to the plasmashell process.
(In reply to Matt Whitlock from comment #113) Matt, I'm not knowledgeable enough to say which memory leak this is, or the precise nature of it, but scrolling the list of widgets doesn't do much for my system as you can see in the first video in my comment #106. When I was using KDE Neon I could get the memory usage to 1GB in a few seconds by doing just that. Keep in mind that Kubuntu 18.04 has backported the Qt patch slated for release with Qt 5.11. As it stands, in practice, Kubuntu's memory seems fine as long as I don't test a new wallpaper to use, or fiddle with the slideshow feature.
(In reply to David Edmundson from comment #112) > @Ovidiu, A packager stating something doesn't necessarily mean much. Can you > point me to the packaging code. Also do you have > https://codereview.qt-project.org/#/c/202781/ which is for a different leak. David, I'm not a packager, nor a Qt/C++ dev so I couldn't point you at much except for user facing stuff. The link looks like a commit. If you're asking if my system has that included, I don't know how to check precisely (I assume it would be in binary form anyway). But you mentioned at some point it should be in Qt >= 5.9.3. Kubuntu 18.04 has 5.9.5. I was hoping someone could reproduce what I showed in the videos, with the known fixes applied: either switch wallpapers manually for a couple of minutes or start a slideshow with 4k images and change from 3s to 2s in the middle of it. Memory should increase continuously and not be released.
(In reply to Ovidiu Chi from comment #114) > Matt, I'm not knowledgeable enough to say which memory leak this is, or the > precise nature of it, but scrolling the list of widgets doesn't do much for > my system as you can see in the first video in my comment #106. When I was > using KDE Neon I could get the memory usage to 1GB in a few seconds by doing > just that. The leak demonstrated by rapidly scrolling the list of available widgets occurs *much* more slowly on my system now than it used to. I too could previously get plasmashell up over 1 GB in under a minute. I tried again just now and was able to bloat it up from just under 200 MB to over 300 MB with about five minutes of scrolling the widgets list. So it's *better* but still not totally solved. The leak demonstrated by the slideshow is fully gone for me. I am running a slideshow of 2560x1600 images every 2 seconds with QSG_RENDER_LOOP=basic as I write this, and both plasmashell's memory usage and the VRAM usage (as reported by radeontop) are remaining in a narrow range.
> I am running a slideshow of 2560x1600 images every 2 seconds with QSG_RENDER_LOOP=basic @Matt, You'd have to start the slideshow then, after a little while(a few seconds), change the duration (e.g. from 3s to 2s). I did some more tests. I set `export QSG_RENDER_LOOP=threaded` in `~/.config/plasma-workspace/env/env.sh` and logged back in. I cannot reproduce the problem anymore. The memory either doesn't increase or rises very little and gets freed afterwards. Everything looks stable. I then set `export QSG_RENDER_LOOP=basic` in the same file and I could reproduce again. So it seems Kubuntu 18.04 is set to `basic` by default. I entered `QSG_INFO=1 plasmashell` in the terminal to find out the value, but nothing is displayed. I don't know if the behavior is the same on all graphic cards. If someone is able to test this out, great, otherwise it will be another tweak I need to write down. System details: CPU: Intel i7-6700HQ (8) @ 3.500GHz GPU: Intel HD Graphics 530 GPU: NVIDIA GeForce GTX 960M OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2) I have not installed the Nvidia drivers. I've set GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nouveau.modeset=0" in `/etc/default/grub` so I can log in, shut down and suspend the laptop properly.
>. I entered `QSG_INFO=1 plasmashell` in the terminal to find out the value, but nothing is displayed. You need to quit the old plasmashell beforehand. >So it seems Kubuntu 18.04 is set to `basic` by default. Qt swtiched based on graphic driver. Some don't support GL use in threads. ----- As for Kubuntu. Looking at http://archive.ubuntu.com/ubuntu/pool/universe/q/qtdeclarative-opensource-src/qtdeclarative-opensource-src_5.9.5-0ubuntu1.debian.tar.xz from https://packages.ubuntu.com/source/bionic/qtdeclarative-opensource-src I do not see my patch applied.
Which fix is it lacking, David? https://codereview.qt-project.org/#/c/224684/ or https://codereview.qt-project.org/#/c/202781/? Or both? :/ Either way, I'll go get this fixed...
(In reply to Ovidiu Chi from comment #117) > > I am running a slideshow of 2560x1600 images every 2 seconds with QSG_RENDER_LOOP=basic > > @Matt, You'd have to start the slideshow then, after a little while(a few > seconds), change the duration (e.g. from 3s to 2s). Okay, I have restarted plasmashell with QSG_RENDER_LOOP=basic QSG_INFO=1, and I do indeed see this in the output: qt.scenegraph.general: QSG: basic render loop I set a slideshow at an interval of 3 seconds and started monitoring plasmashell's memory usage and VRAM usage. It has been a few minutes, and I see no extreme rise in memory usage. (Plasmashell, since it hosts a garbage-collected runtime environment, does grow in memory usage for a little while after startup until it is "warm.") Something I forgot to mention before: I do make sure to show some tooltips in the task switcher, pop up the applications menu, pop up the calendar, etc., to be certain that there are some previously rendered but now hidden windows. This was the trigger of the logic bug originally. Now I change the slideshow interval from 3 seconds to 2 seconds. I observe no extreme increase in plasmashell's memory usage or VRAM usage. Plasmashell's usage still gently rises over time, due to the other leak, which is still unaddressed, but the major VRAM leak is not present. (In reply to David Edmundson from comment #118) > Qt [switches] based on graphic driver. Some don't support GL use in threads. You would think that Mesa/Gallium/RadeonSI (AMDGPU) would be modern enough for Qt to use the threaded renderer by default, but "basic" is still the default on my system. I am going to leave the QSG_RENDER_LOOP=threaded in my session environment, as I experience no problems with it whatsoever.
@Nate I can't see https://codereview.qt-project.org/#/c/224684/ in the debian packaging tarball. It's in the debian packaging git repo though.
So, i open another one, it is simpler. Could you guys please test? It is a plasma js script that will use all of my memory just re-aligning folderview icons over and over Here: https://bugs.kde.org/show_bug.cgi?id=394436
@Nate @David Appears the mentioned fix is in debian packaging repo for their master branch, but not in the ubuntu/bionic branch used for Ubuntu 5.9.x uploads. At a guess, as the launchpad bug was marked as fixed, I would guess that was an oversight, or it was thought the fix was in 5.9.5 tars themselves. Letting Qt guys know.
Memory leak still present with Kubuntu 18.04 updated as follows: Plasma 5.12.5 FW 5.44.0 QT 5.9.5 HW: Toshiba Satellite laptop, Intel graphics Both the media frame widget and desktop background are affected. Setting the update interval to 10s (or less) and parking a memory widget on the desktop was the method used for monitoring. Note: pkill plasmashell; QSG_RENDER_LOOP=threaded kstart plasmashell also stopped the leak.
Thanks Rik. I'd love to know what you hear. It would be nice to finally get this fixed in Kubuntu once and for all.
*** Bug 392505 has been marked as a duplicate of this bug. ***
(In reply to Rik Mills from comment #123) @Rik Mills @Nate Graham Would you please alert this thread when the fixes have made their way into the Kubuntu 18.04 repositories. I'm waiting on updating until this fix has trickled down, because it is crippling bad for my system.
(In reply to cdobrich from comment #127) > (In reply to Rik Mills from comment #123) > @Rik Mills @Nate Graham > > Would you please alert this thread when the fixes have made their way into > the Kubuntu 18.04 repositories. I'm waiting on updating until this fix has > trickled down, because it is crippling bad for my system. I have the same problem. It took me ages to find that plasmashell and the slideshow is the problem .... almost ditched Kubuntu 18.04 completely.
What's the story with this? Because it is apparently still happening with qt5-5.11.1-9.fc29.x86_64... (I just killed a plasma that had ballooned to almost 27G VIRT.)
Virtual memory is not a relevant measure of anything useful. Only Res + Shared matter. If you do think you have an issue with memory and confirm you have https://codereview.qt-project.org/#/c/224684/ applied please open a new bug with as much relevant new information as possible.
> Virtual memory is not a relevant measure of anything useful. That is neither necessarily true, nor necessarily untrue. While I have seen instances of processes having huge VIRT that didn't correspond to real memory usage (e.g. 256G VIRT with reasonable RES), most of the time there is a strong correlation between VIRT and actual memory use. (The other problem with RES is it doesn't account for "real" memory that has been swapped out, AFAIK. IMO both are useful measurements.) At any rate, RES was insane also. Here's the full htop line: 1893 matthew 20 0 26.9G 17.1G 20308 S 0.3 54.5 3h10:59 /usr/bin/plasmashell I doubt I can provide any *new* information. I'm using slideshow wallpaper. After a while (not sure if it is "always" or somewhat at random; I only just upgraded to F29 about a week or so ago), memory usage grows to unreasonable size. The only thing I know that's "new" is that this is still happening with qt5-5.11.1-9.fc29.x86_64. (Based on inspecting the debuginfo sources, I *do* have 224684 applied.)