| Summary: | Memory Leak in plasmashell - with heaptrack data. | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Andy <kde.20.andromodon> |
| Component: | generic-performance | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | boite.pour.spam, hein, kde, nate, sitter |
| Priority: | HI | Keywords: | efficiency-and-performance |
| Version First Reported In: | 6.3.6 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Configuration file with issue | ||
Thank you for the bug report! However Plasma 6.3.6 no longer receives updates or maintenance from KDE; active versions are 6.4 or newer. Please upgrade to an active version as soon as your distribution makes it available to you. Plasma is a fast-moving project, and bugs in one version are often fixed in the next one. If you need help with Plasma 6.3.6, please contact your distribution, who bears the responsibility of providing help for older releases that are no longer receiving updates from KDE. If you can reproduce the issue after upgrading to an active version, feel free to re-open this bug report. (In reply to Bug Janitor Service from comment #1) > Thank you for the bug report! > > However Plasma 6.3.6 no longer receives updates or maintenance from KDE; > active versions are 6.4 or newer. Please upgrade to an active version as > soon as your distribution makes it available to you. Plasma is a fast-moving > project, and bugs in one version are often fixed in the next one. > > If you need help with Plasma 6.3.6, please contact your distribution, who > bears the responsibility of providing help for older releases that are no > longer receiving updates from KDE. > > If you can reproduce the issue after upgrading to an active version, feel > free to re-open this bug report. Debian Trixie was literally JUST released as stable. I hope KDE isn't "out of support" before it's marked stable. That would be a pretty ridiculous situation indeed. If the KDE in "stable" version of debian is broken, I'd hate to try the "testing" version. Seems like it would be even more broken. Anyway, I provided all the info someone should need to find the exact line of code causing the issue. Once the issue is found, if that same code is in the latest KDE then we still have an issue. I hope someone will take the time to check as I spent my whole day gathering data for this effort. > Debian Trixie was literally JUST released as stable.
Alas, you need to talk to debian about shipping outdated software then.
>. I hope someone will take the time to check as I spent my whole day gathering data for this effort.
Just to be clear, it is appreciated and we'll look through it.
Any frustrating about software versions is aimed at Debian not you.
From the trace, we're in the code that reads through $XDG_DATA_DIRS/share/applications . That code hasn't been changed in years, so we're probably hitting an unusual case rather than it being a regression. The code ksycoca uses is based on timestamps of when we last indexed and the last updates in the relevant folders. I strongly suspect one of these folders /usr/share/applications .local/share/applications etc. has a timestamp in the future. Output of QT_LOGGING_RULES=kf.service.services.debug=true plasmashell --replace when we're going haywire would be the most helpful. (In reply to David Edmundson from comment #6) > From the trace, we're in the code that reads through > $XDG_DATA_DIRS/share/applications . That code hasn't been changed in years, > so we're probably hitting an unusual case rather than it being a regression. > > The code ksycoca uses is based on timestamps of when we last indexed and the > last updates in the relevant folders. I strongly suspect one of these > folders /usr/share/applications .local/share/applications etc. has a > timestamp in the future. > > Output of > QT_LOGGING_RULES=kf.service.services.debug=true plasmashell --replace > > when we're going haywire would be the most helpful. Thank you for looking into this. Yeah I get your frustration about trying to make progress on KDE while being pressured to support versions that are 2-3 years old, and how difficult it must be to try and keep that much code in your head at once. I think everyone wants a good user experience and your strategy (have everyone use the latest version) and their strategy (have everyone use the version that has had the longest time to be debugged and fixed) just aren't aligning. Anyway it's much bigger than you and me. Thank you for your help. Here is some data about your hunch: ``` [<usernameRedacted>@<hostRedacted> tmp]$ echo "$XDG_DATA_DIRS" /usr/share/xfce4:/usr/share/gnome:/home/<usernameRedacted>/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share [<usernameRedacted>@<hostRedacted> tmp]$ sudo su [root@<hostRedacted> tmp]$ find /usr/share/xfce4 /usr/share/gnome /home/<usernameRedacted>/.local/share/flatpak/exports/share /var/lib/flatpak/exports/share /usr/local/share /usr/share -type d -newerct now find: ‘/home/<usernameRedacted>/.local/share/flatpak/exports/share’: No such file or directory [root@<hostRedacted> tmp]$ find /usr/share/xfce4 /usr/share/gnome /home/<usernameRedacted>/.local/share/flatpak/exports/share /var/lib/flatpak/exports/share /usr/local/share /usr/share -type d -newermt now find: ‘/home/<usernameRedacted>/.local/share/flatpak/exports/share’: No such file or directory [root@<hostRedacted> tmp]$ find /usr/share/xfce4 /usr/share/gnome /home/<usernameRedacted>/.local/share/flatpak/exports/share /var/lib/flatpak/exports/share /usr/local/share /usr/share -type d -newerat now find: ‘/home/<usernameRedacted>/.local/share/flatpak/exports/share’: No such file or directory ``` I redacted some parts for privacy. Besides one folder in the $XDG_DATA_DIRS no longer existing, `find` could not find any files with create, modify, or access in the future. Because of the pain of running out of memory every few hours, I've switched to xfce temporarily. I'll try to run the command you requested next time I log in fresh. I do prefer KDE so I hope we can get to the bottom of this together. What is the minimum file set that interacts with the relevant code. Can tar.gz some directories that will allow you to reproduce this on your end and hasten our dev feedback loop? Right now it's gonna be about a 24-48h loop because of time zone differences. As a developer myself I've learned that the faster the loop is, the more effective we are. Here is the output you requested: ```[<userRedacted>@<hostRedacted> ~]$ QT_LOGGING_RULES=kf.service.services.debug=true plasmashell --replace kf.plasma.core: Applet invalid: Cannot find a package for "org.kde.plasma.systemloadviewer" kf.plasma.quick: Applet preload policy set to 1 kf.service.services: query for mimeType "application/octet-stream" returning 0 offers kf.service.services: query for mimeType "application/octet-stream" returning 0 offers file:///usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/main.qml:178:25: QML FolderViewDropArea (parent or ancestor of QQuickLayoutAttached): Binding loop detected for property "minimumWidth": file:///usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/main.qml:201:9 Toolbox not loading, toolbox package is either invalid or disabled. file:///usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/main.qml:178:25: QML FolderViewDropArea (parent or ancestor of QQuickLayoutAttached): Binding loop detected for property "minimumWidth": file:///usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/main.qml:201:9 Toolbox not loading, toolbox package is either invalid or disabled. kf.service.services: query returning 0 offers kf.service.services: query returning 0 offers kf.service.services: query returning 1 offers kf.service.services: query for mimeType "x-scheme-handler/http" returning 7 offers kf.service.services: query returning 0 offers kf.service.services: query returning 0 offers kf.service.services: query returning 1 offers kf.service.services: query for mimeType "x-scheme-handler/http" returning 7 offers kf.service.services: query for mimeType "x-scheme-handler/http" returning 7 offers kf.service.services: query for mimeType "x-scheme-handler/http" returning 7 offers kf.service.services: query for mimeType "x-scheme-handler/http" returning 7 offers kf.service.services: query for mimeType "x-scheme-handler/http" returning 7 offers kf.service.services: query for mimeType "x-scheme-handler/http" returning 7 offers kf.service.services: query returning 0 offers kf.service.services: query returning 0 offers kf.service.services: query returning 1 offers kf.service.services: query for mimeType "x-scheme-handler/http" returning 7 offers kf.service.services: query for mimeType "x-scheme-handler/http" returning 7 offers kf.service.services: query for mimeType "x-scheme-handler/http" returning 7 offers kf.service.services: query for mimeType "x-scheme-handler/http" returning 7 offers kf.service.services: query for mimeType "x-scheme-handler/http" returning 7 offers kf.service.services: query for mimeType "x-scheme-handler/http" returning 7 offers kf.service.services: query returning 0 offers kf.service.services: query returning 0 offers kf.service.services: query returning 1 offers <repeats the last 9 lines about once every second>``` I'm running Manjaro and since the last update (done today, but I haven't updated in the last month), I'm getting the same issues as the OP: plasmashell takes 100% CPU and leaks memory (and is so slow it's unusable). Operating System: Manjaro Linux KDE Plasma Version: 6.3.6 KDE Frameworks Version: 6.17.0 Qt Version: 6.9.1 Kernel Version: 6.15.9-2-MANJARO (64-bit) Graphics Platform: Wayland Processors: 16 × Intel® Core™ i7-10875H CPU @ 2.30GHz Memory: 31.1 Gio of RAM Graphics Processor: Mesa Intel® UHD Graphics Manufacturer: Dell Inc. Product Name: Precision 5550 I've updated my system to unstable version, that is, using Plasma 6.4 and the issue remains: Operating System: Manjaro Linux KDE Plasma Version: 6.4.4 KDE Frameworks Version: 6.17.0 Qt Version: 6.9.1 Kernel Version: 6.15.11-1-MANJARO (64-bit) Graphics Platform: Wayland Processors: 16 × Intel® Core™ i7-10875H CPU @ 2.30GHz Memory: 32 Gio of RAM (31.1 Gio usable) Graphics Processor: Mesa Intel® UHD Graphics Manufacturer: Dell Inc. Product Name: Precision 5550 For what it's worth, since the output from the above command almost gives the same output, I've strace'd plasmashell to understand what it's doing, and it's doing this in a (very fast) loop:
clone3({flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, child_tid=0x7fbf311fa990, parent_tid=0x7fbf311fa990, exit_signal=0, stack=0x7fbf309fa000, stack_size=0x7ffc80, tls=0x7fbf311fa6c0} => {parent_tid=[118569]}, 88) = 118569
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
fcntl(75, F_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=124, l_len=1}) = 0
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
write(5, "\1\0\0\0\0\0\0\0", 8) = 8
ppoll([{fd=5, events=POLLIN}, {fd=14, events=POLLIN}, {fd=20, events=POLLIN}, {fd=27, events=POLLIN}, {fd=30, events=POLLIN}, {fd=32, events=POLLIN}, {fd=33, events=POLLIN}, {fd=34, events=POLLIN}, {fd=50, events=POLLIN}, {fd=55, events=POLLIN}, {fd=56, events=POLLIN}, {fd=59, events=POLLIN}, {fd=60, events=POLLIN}, {fd=72, events=POLLIN}, {fd=79, events=POLLIN}, {fd=80, events=POLLIN}, {fd=83, events=POLLIN}, {fd=88, events=POLLIN}, {fd=89, events=POLLIN}, {fd=96, events=POLLIN}], 20, {tv_sec=0, tv_nsec=0}, NULL, 8) = 1 ([{fd=5, revents=POLLIN}], left {tv_sec=0, tv_nsec=0})
read(5, "\2\0\0\0\0\0\0\0", 8) = 8
write(4, "\1\0\0\0\0\0\0\0", 8) = 8
ppoll([{fd=5, events=POLLIN}, {fd=14, events=POLLIN}, {fd=20, events=POLLIN}, {fd=27, events=POLLIN}, {fd=30, events=POLLIN}, {fd=32, events=POLLIN}, {fd=33, events=POLLIN}, {fd=34, events=POLLIN}, {fd=50, events=POLLIN}, {fd=55, events=POLLIN}, {fd=56, events=POLLIN}, {fd=59, events=POLLIN}, {fd=60, events=POLLIN}, {fd=72, events=POLLIN}, {fd=79, events=POLLIN}, {fd=80, events=POLLIN}, {fd=83, events=POLLIN}, {fd=88, events=POLLIN}, {fd=89, events=POLLIN}, {fd=96, events=POLLIN}], 20, {tv_sec=0, tv_nsec=14000000}, NULL, 8) = 1 ([{fd=5, revents=POLLIN}], left {tv_sec=0, tv_nsec=11248968})
read(5, "\3\0\0\0\0\0\0\0", 8) = 8
fcntl(75, F_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=124, l_len=1}) = 0
fcntl(75, F_SETLK, {l_type=F_UNLCK, l_whence=SEEK_SET, l_start=124, l_len=1}) = 0
fcntl(75, F_SETLK, {l_type=F_RDLCK, l_whence=SEEK_SET, l_start=124, l_len=1}) = 0
pread64(73, "\0\0\0\0lpga8eDtu-2FahbE2-2FYmVy59Lb"..., 1089, 3850240) = 1089
pread64(73, "\0\0\0\0lpga8eDtu-2FahbE2-2FYmVy59Lb"..., 1089, 3850240) = 1089
pread64(73, "\0\0\0\0lpga8eDtu-2FahbE2-2FYmVy59Lb"..., 1087, 3850240) = 1087
pread64(73, "\0\0\0\0lpga8eDtu-2FahbE2-2FYmVy59Lb"..., 1087, 3850240) = 1087
pread64(73, "\0\0\0\0lpga8eDtu-2FahbE2-2FYmVy59Lb"..., 1087, 3850240) = 1087
pread64(73, "\0\0\0\0lpga8eDtu-2FahbE2-2FYmVy59Lb"..., 1087, 3850240) = 1087
pread64(73, "\0\0\0\0lpga8eDtu-2FahbE2-2FYmVy59Lb"..., 1087, 3850240) = 1087
rt_sigprocmask(SIG_BLOCK, ~[], [], 8) = 0
Ok, I think I've found the culprit (but nuked my plasma customization meanwhile). As soon as you add a "org.kde.plasma.kickerdash" widget to the menu bar, plasmashell starts consuming CPU like a crazy dog. It's completely lazy with "org.kde.plasma.kickoff" (less than 1% CPU) but explode to 100% with kickerdash (which is called something like "Application panel board" / "Tableau de bord des applications"). There's something very wrong with this widget in the last versions, and I don't know why. Created attachment 184530 [details]
Configuration file with issue
Change the line that read:
plugin=org.kde.plasma.kickerdash
to:
plugin=org.kde.plasma.kickoff
to see the bug disappear.
Hi boiite, Thanks for trying to move this ball down the field a bit. I'm afraid we may be seeing two different issues with similar symptoms, as I do not use the kickerdash widget. Between my heaptrack and your strace, I feel like a KDE developer could solve this in a day if we could just get someones attention.... I'm having to choose between debugging someone else's code, or spending a day of my time reverting my system to a version of debian that is going to be EOL in a year. One really shouldn't have to do that. "Stable" should mean stable! :( It breaks trust to ship something that is broken, especially when it worked before! Andy The bug about kickerdash is: https://bugs.kde.org/show_bug.cgi?id=507893 Edit. We had a different bug about kickerdash (that only affects master). I might have been too quick to comment. If your symptoms match it could well be the same thing. The original traces from Andy do show it's libkicker calling into kworkspace / DefaultService::browser in a crazy loop. That plugin is shared with kickerdash. If you have the time, can either of you run with:
> QT_LOGGING_RULES=kf.service.sycoca.debug=true plasmashell --replace
when in the broken state and can you also can you include
ls -lh ~/.cache/ksycoca6-*
I'm sorry I won't be of any help any longer. I couldn't stand to use debian trixie with this plasma memory leak and blutooth glitches. I tried switching to xfce but it just didn't feel right, so I spent the last 2 days reverting to bookworm. It's a sad thing to do, but I had to think of my productivity and I wasn't confident this was going to be fixed soon enough. I'll need to upgrade again when bookworm goes End of Life, so I hope things will be fixed by then. Good luck! (In reply to David Edmundson from comment #17) > If you have the time, can either of you run with: > > > QT_LOGGING_RULES=kf.service.sycoca.debug=true plasmashell --replace > > when in the broken state and can you also can you include > > ls -lh ~/.cache/ksycoca6-* I'll come back to you on monday. I'm not able to reproduce the issue I had. I've reverted my system back to Plasma 6.3 (I prefer to stay on Manjaro "Stable"). I've removed many applications I don't use anymore (because going from Stable to Unstable broke them or vice versa). In the end, I've rebooted a number of time and plasmashell doesn't eat CPU like it did last Friday. Ok, thanks for the feedback both of you. I'll keep an eye out for similar reports and will have a headstart on getting that in the right direction. 🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone! 🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME. |
SUMMARY There are numerous reports of memory leaks in plasmashell, but few have enough details to actually enable efficient troubleshooting. I hope to provide all of the info for us to be able to get to the bottom of this. I'm running debian trixie. The exact package versions I'm using can be found in the DATA section, below. STEPS TO REPRODUCE 1. run `htop`. Observe that plasmashell is using less than 700MB of RES Ram. 2. Run kde for 6 hours 3. Observe that for most of this, plasmashell is using 100% CPU. 2. Observe that plasmashell is using more than 2G of RES Ram. If left alone, it will keep eating ram until the system runs out. EXPECTED RESULT No memory leak. Stable performance POSSIBLE CONFOUNDING FACTOR This may or may not be related to an error I got when trying to add a shortcut to the shortcuts settings. When I tried to add the shortcut I got a "Error while communicating with the global shortcuts service" with these lines in my system log: 2025-08-18T11:07:07.722037+08:00 localhost org.kde.ActivityManager[311980]: org.kde.kactivities.resources: "INSERT INTO ResourceEvent (usedActivity, initiatingAgent, targettedResource, start, end) VALUES (:usedActivity, :initiatingAgent, :targettedResource, :start, :end)" 2025-08-18T11:07:07.722383+08:00 localhost org.kde.ActivityManager[311980]: org.kde.kactivities.resources: QSqlError("5", "Unable to fetch row", "database is locked") 2025-08-18T11:07:09.771753+08:00 localhost org.kde.ActivityManager[311980]: org.kde.kactivities.resources: "UPDATE ResourceScoreCache SET cachedScore = :cachedScore, lastUpdate = :lastUpdate WHERE :usedActivity = usedActivity AND :initiatingAgent = initiatingAgent AND :targettedResource = targettedResource " 2025-08-18T11:07:09.771850+08:00 localhost org.kde.ActivityManager[311980]: org.kde.kactivities.resources: QSqlError("5", "Unable to fetch row", "database is locked") 2025-08-18T11:07:10.330716+08:00 localhost systemsettings[357445]: org.kde.kcm_keys: "Error while calling objectPath of added applicationnet.local.screenDim.desktop" 2025-08-18T11:07:10.330952+08:00 localhost systemsettings[357445]: org.kde.kcm_keys: "org.kde.kglobalaccel.NoSuchComponent" "The component 'net.local.screenDim.desktop' doesn't exist." After that, kglobalacceld slowly started increasing it's RES memory size as well, up to nearly 1GB. It'll do more if I leave it longer. I'm not sure if these are two separate issues or if the problem is related to the interaction between the two components. DATA: I'm attaching the packages I have installed and the heaptrack dumps and heaptrack_print analysis for both plasmashell and kglobalacceld here with the hope they will be useful in tracking down the issue(s): https://drive.google.com/drive/u/0/folders/1dMye3iIzLqhckoXydLYyQ4-cSzbbLeAL REQUEST: I'd specifically like to avoid the typical "try this and see if it works" back and forth. That ends up being very time consuming for both of us in the end, and since a single experiment is 6-12h long, exasperating. Maybe that's why this specific bug hasn't been fixed yet. I think a better approach is to focus on how I can either run a single command on my machine that gives you all of the information you need to find the exact line of code that is at fault or how I can get you a suitable replication of my setup so you can reproduce the issue yourself and troubleshoot without me in the loop. If this heaptrack isn't precisely what you need, then what commands would you like me to run that would give you 99% certainty that you will have what you need to pinpoint the issue in one go?