Description of problem: The kded4 binary just keeps growing, albeit slowly. Currently the one on my desktop is at 4G resident size and 6.3G virtual size (it's eating a quarter of my RAM!). The top program shows this: 2400 dhowells 20 0 6331m 4.0g 11m S 0.0 25.7 24:06.05 kded4 I have had to reboot my machine previously because kded4 had over 8G of RSS and my machine was swapping like crazy and becoming unresponsive. Upgrading from an earlier F17 version of kdelibs didn't help. Version-Release number of selected component (if applicable): kdelibs-4.9.2-5.fc17.x86_64 How reproducible: 100%. It's just slow to do so. Steps to Reproduce: 1. Start KDE. 2. Do stuff. 3. Wait, and keep an eye on the size of kded4 in top. I might be able to valgrind it, but I don't know how to insinuate valgrind in there when it is started.
Created attachment 636011 [details] /proc/pid/maps
Created attachment 636012 [details] /proc/pid/status
Could you please check System Settings -> Startup and Shutdown -> Service Manager and list running services so that it's easier for me to reproduce?
Running load-on-demand services: Cookie Jar Favicons Konqueror Browser Preloader Startup Services running: Apper Monitor Blue Devil Display Management change monitor DNS-SD Service Discovery Monitor Drive Ejector Free Space Notifier Input Actions K Remote Control Dæmon Keyboard Dæmon KMixD Nepomuk Search Module Network Status NetworkManager User Settings Service ObexFTP Power Management Remote URL Change Notifier Removable Device Automounter Status Notifier Manager Time Zone Write Dæmon Note that I have managed to kill kded4 and run it up under valgrind with: valgrind --log-file=kded4.memcheck --leak-check=full --show-possibly-lost=no --show-reachable=no --undef-value-errors=no kded4
Note that I'm not running on a laptop, so suspend/resume shouldn't be an issue.
Thanks. I just briefly tried in VM and found 3 or 4 leaks here and there, but nothing major that would cause what you describe. To properly run kded4 in valgrind, you have to run valgrind --log-file=kded4.memcheck --leak-check=full --show-possibly-lost=no --show-reachable=no --undef-value-errors=no kded4 --nofork To properly shutdown kded4, run dbus-send --dest=org.kde.kded /MainApplication org.kde.KApplication.quit
It seems you don't actually need to use '--nofork'. Valgrind will follow the fork and dump states for all the processes into the log separately. However, I've restarted it with "--nofork" and I've attached the old log file here (look for process 3695). There was ~53M of possibly lost memory and ~40K of definitely or indirectly lost memory. Memory allocated by a new in QLibraryPrivate::findOrCreate(QString const&, QString const&) seems to be the biggest source of potential leaks (~13,500 blocks). I've also taken the opportunity to load some missing debuginfo packages to flesh out the '???' notes in the valgrind log. Note that your suggested dbus-send command doesn't seem to achieve anything and I had send SIGTERM to kded4.
Created attachment 636275 [details] kded4 valgrind log without --nofork specified
As explained here [0], the QLibrary is not really a leak since the data are static and are released by OS when application exists. FontConfig does not leak as well. I will try to fix the smaller leaks, however I don't see any way to handle the huge growth you described. [0] https://bugreports.qt-project.org/browse/QTBUG-25279
This seems to be fixed in kdelibs-4.9.3-2.fc17.x86_64
This is not fixed in kdelibs-4.10.2-2.fc18.x86_64. I have a new valgrind log that I will attach. The summary is: ==3507== LEAK SUMMARY: ==3507== definitely lost: 9,169 bytes in 99 blocks ==3507== indirectly lost: 46,452 bytes in 723 blocks ==3507== possibly lost: 89,774,583 bytes in 811,684 blocks ==3507== still reachable: 8,407,851 bytes in 112,684 blocks ==3507== suppressed: 0 bytes in 0 blocks At this point the X server crashed because the kernel noveau driver went beserk - so I'm not sure the exit was entirely clean. However, I'm definitely seeing kded4 inexorably growing to multiple gigabytes of resident memory. Mostly the blocks are losses in Qt as you pointed out in comment 9. Reading the Qt bug report you refer to, it's not clear that it isn't a real leak (see Axel Rasmussen's comment on the 14th May 2012). Valgrind is of the opinion that over 800 pieces of memory of lost. Axel's comment is that "those pointers are lost without ever being freed" - which sounds like a bug, though maybe he didn't mean that exactly.
Created attachment 754030 [details] another kded4 valgrind log Another valgrind log. Note that three processes are logged here. The main one is 3507 which brackets the other two. The relevant leak summary is at the bottom of the file.
We probably will want to backport the leak found and fixed in http://bugs.kde.org/324954 may help here.
(In reply to Rex Dieter from comment #13) > We probably will want to backport the leak found and fixed in > http://bugs.kde.org/324954 > > may help here. That seems to be a different bug. As far as I can tell, the kded4 on my system isn't leaking sockets (I'm using kdelibs-4.11.1-4 on F19 now), but is rather gathering memory in Qt without releasing it (see comment 9).
There's also another upstream bug tracking a kded leak in power handling (apparently). http://bugs.kde.org/306206
and http://bugs.kde.org/271934
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Upstream bug, https://bugs.kde.org/show_bug.cgi?id=271934#c121 has tracked the a possible cause to polkit. I'll open a separate bug (against polkit), and link it.
Opened, https://bugzilla.redhat.com/show_bug.cgi?id=1180886
Some patched polkit scratch builds for initial testing: F21: http://koji.fedoraproject.org/koji/taskinfo?taskID=8603571 F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=8603575
polkit-0.112-7.fc21.1 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/polkit-0.112-7.fc21.1
polkit-0.112-7.fc20.1 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/polkit-0.112-7.fc20.1
Package polkit-0.112-7.fc20.1: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing polkit-0.112-7.fc20.1' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-1285/polkit-0.112-7.fc20.1 then log in and leave karma (feedback).
polkit-0.112-7.fc21.1 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
kded4 in f21 doesn't appear to have the memory growth problem. I can't easily check f20 now. It's using polkit-0.112.7.fc21 not the new version.
polkit-0.112-7.fc20.1 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.