Bug 871761 - The kded4 binary slowly grows without limit
Summary: The kded4 binary slowly grows without limit
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kdelibs
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1180886
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-10-31 10:38 UTC by David Howells
Modified: 2015-02-08 08:58 UTC (History)
11 users (show)

Fixed In Version: polkit-0.112-7.fc20.1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-08 08:58:24 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
/proc/pid/maps (114.00 KB, text/plain)
2012-10-31 10:42 UTC, David Howells
no flags Details
/proc/pid/status (961 bytes, text/plain)
2012-10-31 10:43 UTC, David Howells
no flags Details
kded4 valgrind log without --nofork specified (79.71 KB, text/plain)
2012-10-31 18:21 UTC, David Howells
no flags Details
another kded4 valgrind log (38.75 KB, text/plain)
2013-05-28 17:45 UTC, David Howells
no flags Details


Links
System ID Private Priority Status Summary Last Updated
KDE Software Compilation 271934 0 None None None Never
KDE Software Compilation 306206 0 None None None Never
KDE Software Compilation 324954 0 None None None Never
Qt Bug Tracker QTBUG-25279 0 None None None Never

Description David Howells 2012-10-31 10:38:29 UTC
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.

Comment 1 David Howells 2012-10-31 10:42:01 UTC
Created attachment 636011 [details]
/proc/pid/maps

Comment 2 David Howells 2012-10-31 10:43:04 UTC
Created attachment 636012 [details]
/proc/pid/status

Comment 3 Daniel Vrátil 2012-10-31 11:21:22 UTC
Could you please check System Settings -> Startup and Shutdown -> Service Manager and list running services so that it's easier for me to reproduce?

Comment 4 David Howells 2012-10-31 12:59:36 UTC
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

Comment 5 David Howells 2012-10-31 13:01:19 UTC
Note that I'm not running on a laptop, so suspend/resume shouldn't be an issue.

Comment 6 Daniel Vrátil 2012-10-31 13:51:43 UTC
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

Comment 7 David Howells 2012-10-31 18:20:03 UTC
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.

Comment 8 David Howells 2012-10-31 18:21:05 UTC
Created attachment 636275 [details]
kded4 valgrind log without --nofork specified

Comment 9 Daniel Vrátil 2012-11-01 12:55:23 UTC
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

Comment 10 David Howells 2012-11-28 11:31:32 UTC
This seems to be fixed in kdelibs-4.9.3-2.fc17.x86_64

Comment 11 David Howells 2013-05-28 17:33:55 UTC
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.

Comment 12 David Howells 2013-05-28 17:45:52 UTC
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.

Comment 13 Rex Dieter 2013-10-03 12:48:43 UTC
We probably will want to backport the leak found and fixed in http://bugs.kde.org/324954

may help here.

Comment 14 David Howells 2013-10-03 13:09:02 UTC
(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).

Comment 15 Rex Dieter 2013-12-19 19:54:48 UTC
There's also another upstream bug tracking a kded leak in power handling (apparently). http://bugs.kde.org/306206

Comment 16 Rex Dieter 2013-12-19 20:09:29 UTC
and http://bugs.kde.org/271934

Comment 17 Fedora End Of Life 2013-12-21 15:10:16 UTC
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.

Comment 18 Rex Dieter 2015-01-11 14:03:26 UTC
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.

Comment 19 Rex Dieter 2015-01-11 14:10:18 UTC
Opened,
https://bugzilla.redhat.com/show_bug.cgi?id=1180886

Comment 20 Rex Dieter 2015-01-13 12:51:20 UTC
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

Comment 21 Fedora Update System 2015-01-27 15:37:08 UTC
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

Comment 22 Fedora Update System 2015-01-27 15:51:11 UTC
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

Comment 23 Fedora Update System 2015-01-28 20:00:22 UTC
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).

Comment 24 Fedora Update System 2015-02-04 08:03:20 UTC
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.

Comment 25 David Howells 2015-02-04 13:10:14 UTC
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.

Comment 26 Fedora Update System 2015-02-08 08:58:24 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.