Created attachment 59397 [details]
Dependencies

Created attachment 59398 [details]
ProcMaps

Created attachment 59399 [details]
ProcStatus

Created attachment 59400 [details]
screenshot with final state

If this is reproducible, please disable kded4 modules in "System Settings > Startup and Shutdown > Service Manager" to see which one is the culprit.

Some modules cannot be disabled there. To disable such a module, remove its .desktop file from /usr/share/kde4/services/kded/, run kbuildsycoca4, and restart kded4.

The information which module causes the leak helps fixing the issue.

Kded4 slows down the system noticeable.
After starting kded4 / or after booting the system kded4 allways generates one zombie:

 2773 pts/0    00:00:00 kded4
 2781 pts/0    00:00:00 kded4 <defunct>

Sometimes kded4s CPU usage is increasing to 100% and the computer isn't responding. That behavior is similar to a fork bomb, because the process doesn't use one core (of 4), like other hanging processes (-> Normally 1 core at 100% CPU usage)

incarus6, comment #1 also applies to your (maybe related) issue.  Without knowing which kded module is responsible, there is not much we can do.

Sorry, I meant comment #5.

(In reply to comment #7)
> incarus6, comment #1 also applies to your (maybe related) issue.  Without
> knowing which kded module is responsible, there is not much we can do.

I disabled several modules, after a restart KDED4 didn't start another zombie process. I can't say for sure, which module is causing that issue, but I'm pretty sure that KMixD is causing that issue. 
(Other modules were: ObexFTP, BlueDevil (I don't even have bluetooth), Nepomuk, Keyboard-Service (translated), Screenmanager (transl.), Writeservice (? that thing with "write(1)" and "wall(1)", transl.), Userconfiguration for Networkmanager (transl.), notificationhelper (transl.), and a file-change-in-network-notification (don't know how to translate that).

Look at https://bugs.kde.org/show_bug.cgi?id=206317#c45

Maybe my initial guess was not wrong and the battery-related service is the one to blame.

Thanks for investigation, reassigning to power management team for further inspection.

If is there anything useful you can add to that comment, like if you are constantly running on battery or not, if the leak starts showing after a specific action, such as removing batteries or power cord, etc. please add a comment here.

The other bug report mixes three different applications, so it is hard to track what issue is causing what application to leak.

incarus6, if you are sure the defunct kded4 process is caused by KMixD, please file a separate report for KMix. This bug is only about the memory leak.

(In reply to comment #12)
> incarus6, if you are sure the defunct kded4 process is caused by KMixD, please
> file a separate report for KMix. This bug is only about the memory leak.

I found out it was "Notification Helper", I'll write it in a seperate bug report.

About the conditions on this laptop, I can tell that:
* The battery is really worn out (a 3yr old one), so it barely gets charged. It currently lasts about 5 min running or 30min suspended.
* Because of this, the laptop is always plugged to the wall. There is no other power-related task I have performed here (kinda simple, heh).
* I haven't tried removing the battery and letting the thing run _with_ the process started. Maybe the issue is related to the difficult task of guessing how much the battery has charged. That is the next test (I'll let you know in 12 hours or so).

(In reply to comment #11)
> Thanks for investigation, reassigning to power management team for further
> inspection.
> 
> If is there anything useful you can add to that comment, like if you are
> constantly running on battery or not, if the leak starts showing after a
> specific action, such as removing batteries or power cord, etc. please add a
> comment here.
> 
> The other bug report mixes three different applications, so it is hard to track
> what issue is causing what application to leak.

Well, I removed the battery, enabled the Power Management process and rebooted. Let the laptop with AC power only in an idle session for about 12 hours. kded4 stood on about 20-25MB.

Then I just put back on the battery and let it run 2:40 hours more. Now the process is about 640MB size... guess KDE does not like old batteries :/
_____________________________________________
alfabravo@alfabravoTiger:~$ uptime
 21:42:04 up 12:13,  2 users,  load average: 0.16, 0.10, 0.07
alfabravo@alfabravoTiger:~$ ps aux | grep kded
1000      1985  0.0  1.1 637016 42184 ?        Sl   09:29   0:13 kdeinit4: kded4 [kdeinit]                      
1000      5114  0.0  0.0   9144  1036 pts/1    S+   21:42   0:00 grep --color=auto kded
alfabravo@alfabravoTiger:~$ ps aux | grep kded
1000      1985  0.0  1.3 640884 50260 ?        Sl   09:29   0:14 kdeinit4: kded4 [kdeinit]                      
1000      5516  0.0  0.0   9144  1036 pts/1    S+   21:44   0:00 grep --color=auto kded
alfabravo@alfabravoTiger:~$ uptime
 00:19:15 up 14:50,  2 users,  load average: 0.03, 0.07, 0.10
alfabravo@alfabravoTiger:~$ ps aux | grep kded
1000      1985  0.2 17.2 1255420 654080 ?      Sl   May05   1:56 kdeinit4: kded4 [kdeinit]                      
1000      2370  0.0  0.0   9144  1040 pts/1    S+   00:20   0:00 grep --color=auto kded
_____________________________________________
==== Detailed memory information with battery back on ====
Process 1985 - kded4

Summary

The process kded4 (with pid 1985) is using approximately 611.3 MB of memory.
It is using 607.0 MB privately, and a further 27.7 MB that is, or could be, shared with other programs.
Dividing up the shared memory between all the processes sharing that memory we get a reduced shared memory usage of 4.2 MB. Adding that to the private usage, we get the above mentioned total memory footprint of 611.3 MB.
Library Usage

The memory usage of a process is found by adding up the memory usage of each of its libraries, plus the process's own heap, stack and any other mappings, plus the stack of its 3 threads. 

617852 KB	[heap]
256 KB	/usr/lib/libkhotkeysprivate.so.4.6.0
208 KB	/usr/lib/libknmservice.so.4.6.0
204 KB	/usr/lib/libknm_nm.so
192 KB	/usr/lib/libknmui.so.4.6.0

I can confirm Anders observation with a relatively well-functioning notebook battery. Disabling (only) the "Power Management" service seems to stop the massive memory loss.

(Adding myself to CC.)

I can confirm memory leak in kded4 though I'm not sure whether it's battery but this never happened on a PC (CC).

*** This bug has been confirmed by popular vote. ***

*** Bug 276840 has been marked as a duplicate of this bug. ***

I can confirm Andres' bug on my system as well with one difference: kded4 memory usage still grows even with my battery removed before boot.  FWIW, my battery is reported at about 43% of its original capacity (which gives me less than an hour of battery life on this system).

** My System **
PC: HP Pavilion dv1550se laptop
CPU: Intel(R) Pentium(R) M processor 1.60GHz
RAM: 1GB DDR400
Video: Mobile 915GM/GMS/910GML Express Graphics Controller
Sound: 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller
OS: Kubuntu 11.04 i386 w/ KDE SC 4.6.4

Oh, forgot to mention: disabling the power management service works to prevent the memory leak on my system as well.

I can confirm that this issue persists in KDE 4.7.0 (tested using Kubuntu Natty).

Any hope of this being fixed within the KDE 4.7 series?  Having to keep power management disabled on my laptop is causing serious problems, and I really don't want to have to go back to XFCE :(

This bug is still present in KDE 4.7.1 (tested using Kubuntu packages).

Hello, sorry for chiming in late. I'd love to solve this bug as soon as possible. Is any of the reporters able to track which function or class is causing the leak? I can provide guidance to volunteers in case.

Hi Dario,

I am happy to help out any way I can.  In my case, the power management service is what is causing the memory usage to grow.  My system info is listed in comment #20.

Thank you very much Christian :) You would need to run kded4 through Valgrind to help me out. A very quick guide to use Valgrind+memcheck is to be found here: http://www.cprogramming.com/debugging/valgrind.html or here: http://valgrind.org/gallery/linux_mag.html

You should try to get the log from valgrind and post it here as an attachment; that would be the only thing which could serve as a hint in finding out which part is leaking. Feel free to ask me anything if I can be of any help.

Created attachment 64019 [details]
Valgrind log file for kded4 memory leak

Here is the log file generated by running kded4 in valgrind using the following command:

valgrind --tool=memcheck --leak-check=yes kded4

This test was run over the period of two hours during which my computer was mostly idle (I was teaching piano lessons at the time with Thunderbird open, which was occasionally refreshing e-mail & Google calendars).  During this time, I took note of the process memory usage:

 * Shortly after starting valgrind test (6:08 pm): 206,252 KB
 * 6:16 pm: 224,340 KB
 * 7:02 pm: 237,776 KB
 * 8:12 pm: 266,136 KB

Running under valgrind, the kded4 process takes up a lot more RAM initially, as is to be expected, but the behavior is the same: a gradual increase in RAM consumption by the process.

Please let me know if you need me to run any more tests.

Thank you very much Christian: I do not have time now to tackle the log, but from your description it looks like you provided me with what I needed. I will run through it on Friday at the latest, and will report back to you, hopefully with a commit which closes the bug :) Have a great evening!

*** Bug 261200 has been marked as a duplicate of this bug. ***

Unfortunately the Valgrind log is not really useful, as it needs
--leak-check=full. I found another bug which has a valgrind log with all the
needed info, but with missing debug symbols for kded4, making it in fact not
really useful for getting the problem out. If any volunteers would like to join
#solid of freenode to help triaging this bug here it would be great, as
apparently is anything but easy, and I can still not reproduce it.

(In reply to comment #31)
I will make another valgrind log today with the requested option enabled.  What do you mean by "join #solid of freenode"?  How do I do this?

It's an IRC channel - if your valgrind log will be complete there will be no need for that :)

Created attachment 64105 [details]
valgrind log file with --leak-check=full

I didn't run it as long this time, but I noticed something interesting.  The memory leak seems significantly worse when the laptop is idle.  I was working on my laptop during this last test, during which time the memory consumption didn't go up nearly as much.  When I stopped working and just watched the kded4 process memory consumption in the system monitor, then it started going up as normal.  Here's my log:
 * Shortly after starting valgrind test (2:27 pm): 206,252 KB
 * 2:37 pm: 226,120 KB
 * 2:57 pm: 228,460 KB (approx. the last 500 KB of this increase happened during the time that I stopped working and started just watching the system monitor, which was about one minute).

I am also going to run another valgrind test with --trace-children=yes, in case that will be helpful for you.

Please do. There is no trace of power management in your last log - although, maybe I have an indication, since apparently Polkit-Qt1/KAuth seem to be pretty much everywhere. But I'll wait for your next log before confirming that.

Created attachment 64106 [details]
valgrind log file with --trace-children=yes

Here is a valgrind log file created with --leak-check=full --trace-children=yes.  I left the computer idle for a bit while I grabbed some food, and the memory consumption went up quite a bit while I was away.  My notes:
 * Shortly after starting valgrind test (3:03 pm): 205,940 KB
 * 3:17 pm: 225,360 KB
 * 3:32 pm: 223,116 KB (not sure why this went down... after this time I left to get lunch)
 * 4:50 pm: 263,132 KB

The problem appears to be a leak in Polkit-Qt1/polkit-1. The reason why powermanagement is the trigger for this is the fact brightness controls strongly rely upon polkit actions.

When I was checking this bug, I found it strongly related to battery
management. I removed the battery and ran on AC and found that the leak did
not show up, probably because of the settings for AC power (no fade out
while idle, etc).

Sorry about not helping with valgrind logs, but now I went back to gnome.
Good luck with it.

On Fri, Sep 30, 2011 at 6:28 PM, Dario Freddi <drf@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=271934
>
>
> Dario Freddi <drf@kde.org> changed:
>
>           What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>              Status|NEW                         |ASSIGNED
>          Component|powermanagement-daemon      |general
>            Product|solid                       |policykit-kde
>
>
>
>
> --- Comment #37 from Dario Freddi <drf kde org>  2011-09-30 23:28:02 ---
> The problem appears to be a leak in Polkit-Qt1/polkit-1. The reason why
> powermanagement is the trigger for this is the fact brightness controls
> strongly rely upon polkit actions.
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.
>

*** Bug 285902 has been marked as a duplicate of this bug. ***

I can confirm that this issue persists in KDE 4.7.2 Kubuntu 10.10 64 bit on HP 6820s with an old battery.

This is no doubt power managment service. I disabled it, and volla, no leaks.
(and kded used to take ~250MB of memory before I noticed that something is going on).

It sucks though with this service disabled.

Created attachment 66522 [details]
valgrind log on my system

Ok, here is valgrind log of kded4. Huge leak happens during suspend/resume, seems to be related to fact that after resume, briefly battery icon turns into 'battery absent', and while it is in this state, kded4 grows its memory usage very fast.

Looking at valgrind output, I strongly suspect that commands send to upower fail, and memory used for dbus is not freed.

Besides that, there are so many leaks 8-). sad.

Ladies and gentleman, I bring you good news. After some additional testing on IRC and stuff, I am happy to confirm that upgrading to polkit-qt-1 0.103.0+ fixes this issue!

Thanks to everybody who tested and helped with the valgrind logs, you rock.

I'd venture an educated guess this commit played a major role (kudos),
https://projects.kde.org/projects/kdesupport/polkit-qt-1/repository/revisions/d3c337da01f3887da031fdb5c2ac784fb3e79210

This is truly wonderful news!  Thanks to everyone who was able to make this happen.  MERRY CHRISTMAS!

@Rex: yes, you can find all the infos in the release announcement here: https://projects.kde.org/news/106 . Although, cherry-picking that one will work as well if you have other needs for packaging.

Nope, this bug is not fixed!
I just tried ubuntu package cherry-picked the mentioned commit, I also compiled the library from source and installed to /usr - no change. Each suspend/resume makes kded4 process grow by ~10MB.

That's not neccessarily related, this bug was mainly about kded leaking memory "all by itself", without any manual action like suspend/resume cycles being performed.

I'm also running Ubuntu's libpolkit-qt-1-1 0.99.0-3ubuntu0.1 since yesterday but cannot confirm nor deny that it's fixed so far - I hope I'll find out soon. (The new Akonadi-based PIM framework always uses such enourmous amounts of memory and results in constant paging activity on my poor 2-GB-system that it's not as easy to distinguish this behaviour from a real leak as it was before...)

I nearly forgot to get back to you. The original problem reported in this bug seems to be fixed, or at least the behaviour is *much* better and KDE is actually usable now with power management enabled.

If you see a memory leak on suspend/resume cycles, that's a different bug which should be reported separately.

Reported my bug here: https://bugs.kde.org/show_bug.cgi?id=294497

This issue seems to be still valid.

With clean installation of Kubuntu 12.10 beta 2, there is definitely a huge memory leak. In less than 30 minutes of staying in idle after restart all memory is used and system is totally unusable. Disabling power management fixes the issue, so it seems to be exactly the same issue than described here.

Setup:
- HP Proliant Microserver N40L
- 8GB RAM
- Nvidia GT210 GPU
- Kubuntu 12.10 beta 2
- KDE 4.9.2

This bug is still valid. Memory grows when:
- suspended
- AC adapter plugged in
- AC adapter removed

Bug not resolved in KDE 4.9.2. 

I can confirm that the kded4 process grows in memory on Kubuntu 12.10 with KDE 4.9.4. 

This only occurs on my laptop and not om my desktop PC. (Both computers have the same versions of Kubuntu and KDE installed, both up to date.)

This occurs when running the laptop on any state. (AC and on battery, charging and fully charged)

Bug not resolved in KDE 4.9.4. 

I can confirm that the kded4 process grows in memory on Kubuntu 12.10 with KDE 4.9.4. 

This only occurs on my laptop and not om my desktop PC. (Both computers have the same versions of Kubuntu and KDE installed, both up to date.)

This occurs when running the laptop on any state. (AC and on battery, charging and fully charged)

Could you check, if disabling the power management kded module help solving the leak (see comment #5)? If not, you are very likely seeing a different bug. Report a new bug, if you found out, which kded module is responsible.

For more information, see http://kdepepo.wordpress.com/2011/05/11/troubleshooting-kded4-bugs/

(In reply to comment #55)
> Could you check, if disabling the power management kded module help solving
> the leak (see comment #5)? If not, you are very likely seeing a different
> bug. Report a new bug, if you found out, which kded module is responsible.
> 
> For more information, see
> http://kdepepo.wordpress.com/2011/05/11/troubleshooting-kded4-bugs/

I face the same problem.
Disabling Power Management solves the leaking for me.
KDE 4.10, Kubuntu 12.10 64bit

Can I do something to help you find the root of the problem?
I had this problem in KDE 4.9 as well.

how do you disable power management? 

I'm on Ubuntu with kde and in something like 14 hours it eats 6gb of ram

sorry, I didn't see the answer from  Christoph Feck

Leaks for me as well.
Kubuntu 12.04 64 bit with KDE 4.10.2 from backports.
Disabling power management stops the leaking.

Reopening based on recent comments.

Dario, should I reassign it back to solid developers to check if there is another issue (unrelated to policykit)?

(In reply to comment #60)
> Reopening based on recent comments.
> 
> Dario, should I reassign it back to solid developers to check if there is
> another issue (unrelated to policykit)?

Christoph, I can volunteer if I can provide more info to help the debugging process.
I have one laptop that this leak always happens.

I will just need some guidance.

I have already posted my hardware info in a similar bug here since I suspect it might be related to some hardware (a new Dell XPS 13, same installation does not have this problem): https://bugs.kde.org/show_bug.cgi?id=306206

Leaks for me as well, OpenSuse 12.3, KDE 4.10.2. My PC is a desktop (no battery). But after some tests I figured it was caused by powerdevil.desktop; remove it from the services/kded4 directory the leak will stop. 

During the leak I noticed kded4 memory usage goes up a bit once every 5 minutes (it was as regular as clock-work), but changing my energy saving settings (e.g. dim display time) won't affect this timer. What is telling powerdevil.desktop to do something once every 5 minutes?

(In reply to comment #62)
> Leaks for me as well, OpenSuse 12.3, KDE 4.10.2. My PC is a desktop (no
> battery). But after some tests I figured it was caused by
> powerdevil.desktop; remove it from the services/kded4 directory the leak
> will stop. 
> 
> During the leak I noticed kded4 memory usage goes up a bit once every 5
> minutes (it was as regular as clock-work), but changing my energy saving
> settings (e.g. dim display time) won't affect this timer. What is telling
> powerdevil.desktop to do something once every 5 minutes?

Two things you can check here: run 'upower --monitor-detail' and see if there's anything changing when the memory usage increases;  also run kded under valgrind/massif [1] for 20-30 minutes (to get a few rounds of memory increase) or maybe longer.

Something like "kquitapp kded4; valgrind --tool=massif --time-unit=ms --max-snapshots=1000 kded4" and "kquitapp kded4" again when you're done. Then collect the resulting files and attach them to the bug.

[1] http://valgrind.org/docs/manual/ms-manual.html

(In reply to comment #63)

I found out where that 5 minute timer came from, it is really bizarre: it was my cron job that runs 'ps' and stores the results in a log file. (basically my system was crashing with out-of-memory errors in /var/log/messages, so I started collecting ps outputs trying to find the culprit). It is very hard to believe but the leak timer will match whichever time I choose to run the cron, and stopping the cron will stop the leak. The ps script is very simple, I really can't see how it can affect kded4. May be I did something unbelievably stupid to get this happen on my system but I haven't figured out what yet :). Anyway here is the script:

#!/bin/bash
now=$(date +"%Y%m%d%H%M")
ps auxw --sort rss  > /data/logs/log.$now.txt

I will just stop the cron for now. Will try to find another way for my original memory problem. 

I have attached the logs as you asked. Hope you find them useful.

Created attachment 79569 [details]
valgrind kded4 leak every 5 minutes

Created attachment 79578 [details]
dbus-monitor --system output when cron job starts and stops

This can be reproduced with a no-op cron job that starts every minute, e.g. 
$ cat /etc/cron.d/churn
* * * * * root /bin/true

"dbus-monitor --system" reveals that the attached messages are sent every minute on fedora 17 - they seem to be triggered by cron logging in a new root session for the duration of the job. The memory increase comes from gio's gdbusmessage: perhaps it leaks if there's nobody listening to the message or perhaps we're doing something wrong?

I produced a version of  attachment #79569 [details] with glib2 debugging symbols but managed to destroy it by accident before I could attach it to the bug. Anyway the memory increases look like the "possibly lost" reports from attachment #77807 [details] - for example:

==26563== 2,290,528 bytes in 4,618 blocks are possibly lost in loss record 2,488 of 2,488
==26563==    at 0x4C2788A: memalign (vg_replace_malloc.c:727)
==26563==    by 0x4C27925: posix_memalign (vg_replace_malloc.c:876)
==26563==    by 0xCBE2428: slab_allocator_alloc_chunk (gslice.c:1381)
==26563==    by 0xCC29CFA: g_slice_alloc (gslice.c:724)
==26563==    by 0xCBECEBD: g_bytes_new_with_free_func (gbytes.c:173)
==26563==    by 0xCC3CC0B: g_variant_new_from_trusted (gvariant.c:326)
==26563==    by 0x26241825: parse_value_from_blob (gdbusmessage.c:1219)
==26563==    by 0x262419F0: parse_value_from_blob (gdbusmessage.c:1439)
==26563==    by 0x26241BD3: parse_value_from_blob (gdbusmessage.c:1354)
==26563==    by 0x262419F0: parse_value_from_blob (gdbusmessage.c:1439)
==26563==    by 0x26243135: g_dbus_message_new_from_blob (gdbusmessage.c:1793)
==26563==    by 0x2624D674: _g_dbus_worker_do_read_cb (gdbusprivate.c:753)
==26563==    by 0x261EEFB6: g_simple_async_result_complete (gsimpleasyncresult.c:767)
==26563==    by 0x261EF0B8: complete_in_idle_cb (gsimpleasyncresult.c:779)
==26563==    by 0xCC0F824: g_main_context_dispatch (gmain.c:2539)
==26563==    by 0xCC0FB57: g_main_context_iterate.isra.23 (gmain.c:3146)
==26563==    by 0xCC0FF51: g_main_loop_run (gmain.c:3340)
==26563==    by 0x2624B4D5: gdbus_shared_thread_func (gdbusprivate.c:277)
==26563==    by 0xCC32494: g_thread_proxy (gthread.c:801)
==26563==    by 0x7BF7D13: start_thread (pthread_create.c:309)
==26563==    by 0x96AB68C: clone (clone.S:115)

And commenting out all the KAuth stuff in powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp seems to eliminate the memory increases from cron. So it does look likely to be polkit-qt/glib-related.

Having this problem as well using Ubuntu 13.04.  From what I read like all others it's happenning only on my old HP laptop.  Interestingly this problem does not happend on my newer HP 6460 laptop.

I had opened bug #319496 which now I beleive to be identical to this one.  kded4 memory slowly jumps up to 1.5g or RAM after a few suspend/resume.

I have also opened up a launchpad bug entry at https://bugs.launchpad.net/ubuntu/+source/kde4libs/+bug/1177137

After a while the system becomes barely usable / unresponsive due to swap being used and eventually in totality.

*** Bug 319496 has been marked as a duplicate of this bug. ***

I approve

(In reply to comment #63)
> (In reply to comment #62)
> > Leaks for me as well, OpenSuse 12.3, KDE 4.10.2. My PC is a desktop (no
> > battery). But after some tests I figured it was caused by
> > powerdevil.desktop; remove it from the services/kded4 directory the leak
> > will stop. 
Also running openSUSE 12.3, KDE 4.10.2 and PC is a desktop.

> > 
> > During the leak I noticed kded4 memory usage goes up a bit once every 5
> > minutes (it was as regular as clock-work), but changing my energy saving
> > settings (e.g. dim display time) won't affect this timer. What is telling
> > powerdevil.desktop to do something once every 5 minutes?

I have a cronjob running each minute, obviously at x:y:00. Right at that time I see the memory use of kded4 going up. I renamed /usr/share/kde4/services/kded/powerdevil.desktop to /usr/share/kde4/services/kded/powerdevil.desktop.sav and started kbuildsycoca4 and restarted kded4. After that the memory usage of kded4 stayed stable.

> Two things you can check here: run 'upower --monitor-detail' and see if
> there's anything changing when the memory usage increases;  also run kded
> under valgrind/massif [1] for 20-30 minutes (to get a few rounds of memory
> increase) or maybe longer.

Running 'upower --monitor-detail' gives nothing during 10 minutes.

> Something like "kquitapp kded4; valgrind --tool=massif --time-unit=ms
> --max-snapshots=1000 kded4" and "kquitapp kded4" again when you're done.
> Then collect the resulting files and attach them to the bug.

I did the above running valgrind, although I needed 'kquitapp kded' to stop kded4. It delivered two files massif.out.29899 (1492246 bytes) and massif.out.29902 (6276647 bytes). I ran valgrind for about 10 minutes. Don't why two files. I did run valgrind only once. I installed all possible debuginfo files.
Please inform me if you want these massif files.

(In reply to comment #72)
> I did the above running valgrind, although I needed 'kquitapp kded' to stop
> kded4. It delivered two files massif.out.29899 (1492246 bytes) and
> massif.out.29902 (6276647 bytes). I ran valgrind for about 10 minutes. Don't
> why two files. I did run valgrind only once. I installed all possible
> debuginfo files.
> Please inform me if you want these massif files.

They'd be useful if they include references to "parse_value_from_blob" but not if you're missing glib and gio debuginfo and just have lines like "??? (in /usr/lib64/libgio-2.0.so.0.3400.3)". If not, i wouldn't worry about it - we know what triggers the memory leak and can produce our own massif files if needed. But thanks.

Did you manage to look into this, mbriza?

I looked into really fast it but couldn't reproduce any of the leaks so far, possibly because some of them were fixed in the meantime. I'm planning a deeper analysis as soon as possible.

(In reply to comment #73)
> They'd be useful if they include references to "parse_value_from_blob" but
> not if you're missing glib and gio debuginfo and just have lines like "???
> (in /usr/lib64/libgio-2.0.so.0.3400.3)". If not, i wouldn't worry about it -
> we know what triggers the memory leak and can produce our own massif files
> if needed. But thanks.

Using ms_print I have 2980 lines with parse_value_from_blob. I did install the debuginfo for glib and gio. I thought only ??? were in front of /lib64/ld-2.17.so, but analyzing it more shows I still miss debuginfo for /usr/lib64/kde4/kded_networkmanagement.so, /usr/lib64/libpng15.so.15.13.0, /usr/lib64/libudev.so.1.1.6 and /lib64/libdbus-1.so.3.7.2.

If you need these I can install them and rerun valgrind.

The two massif files are attached as .gz files

Created attachment 80130 [details]
first massif.out file

Created attachment 80131 [details]
second massif.out file

(In reply to comment #77)
> Created attachment 80131 [details]
> second massif.out file

This illustrates the problem nicely. Thanks.

I tried running both kded4 and polkit-kde-agent-1 in memcheck and massif yesterday and today I just let it run with the no-op script in cron and it doesn't do anything basically. I've been running for about 4 hours with the script spamming every minute and kded4 still takes 10MB of RAM.
The system is fully updated Fedora 18 with the following packages (I'm sure there's more relevant, ask me if you think I forgot something important please):
polkit-qt-0.103.0-8.fc18.x86_64
polkit-kde-0.99.0-5.fc18.x86_64
qt-4.8.4-17.fc18.x86_64
kde-workspace-4.10.4-1.fc18.x86_64
glib2-2.34.2-2.fc18.x86_64
The polkit-qt is containing my leak and crash fixing commit 4ed9c3fa043b70ee50176c4baacc07d1c73f1fce  which _could_ fix some of the leaks you're reporting. Otherwise, the problem is somewhere else, I suppose..
If you have any spare time, could you please try applying the changes from the commit and test if the problem still appears? Thank you.

(In reply to comment #72)
> I renamed
> /usr/share/kde4/services/kded/powerdevil.desktop to
> /usr/share/kde4/services/kded/powerdevil.desktop.sav and started
> kbuildsycoca4 and restarted kded4. After that the memory usage of kded4
> stayed stable.

 In case it's material, after upgrading to openSUSE 12.3, I had the same memory issue.  Applying the above `rename trick' worked-around the issue.  Memory consumption by the process is stable.

(In reply to comment #80)
>  In case it's material, after upgrading to openSUSE 12.3, I had the same
> memory issue.  Applying the above `rename trick' worked-around the issue. 
> Memory consumption by the process is stable.
I confirm this: openSUSE 12.3 and renaming "fixes" the issue, but power manager is quite important sometimes.

(In reply to comment #81)
> I confirm this: openSUSE 12.3 and renaming "fixes" the issue, but power
> manager is quite important sometimes.

+1. The same in another openSUSE 12.3 64bit system. No more leak after the renaming.

I can confirm this too. After some uptime, kded4 is using about 233 MB of RAM while after a fresh start it barely uses more than 15 MB (total system memory = 9GB). Thankfully I can restart it without re-logging to fix the leak. openSUSE 12.3, KDE 4.10.3.

Created attachment 81082 [details]
Memcheck output for OpenSUSE 12.3 with polkit-qt-1 master

Hi everybody,
after numerous tries and a bit of fighting with how different is SUSE from Fedora I finally managed to get some at least a somewhat reasonable output from Memcheck. I was testing with clean (didn't update) OpenSUSE 12.3 with the necessary tools installed via zypper and compiled polkit-qt-1 master (with the two fixes from me on top of 0.103) in a KVM virtual machine, creating the leaks with some cron jobs... BTW, guys, if anybody involved is reading this, you really should update the package.
In the log, there are only two places where the leaks take place in PolkitQt1 classes, in PolkitQt1::Authority::Private::init() and PolkitQt1::Authority::checkAuthorizationSync. However, in both of these methods, anything I have access to are the libpolkit results which are unref'd properly.
In the log, you can see HUGE leaks in some D-Bus message and GVariant parsing, which are, I suppose, some D-Bus message preparations for some higher-level methods, which are contained somewhere outside the backtraces in the log, unfortunately.
However, I suppose the whole bug should be discussed primarily with the PowerDevil folks, since it's the component that leaks all the memory in the first place. I'm sure identifying the place in it where the leak(s) occurs will be much easier for them than it is for me.
Anyway, to be completely sure, could please somebody test how the problem stands with some recent Glib, polkit and polkit-qt? I really can't replace the libraries on my own in a clean and fast fashion, sorry. :/
Fedora has the following versions:
glib2-2.36.3-2.fc19.x86_64
polkit-0.111-2.fc19.x86_64
polkit-qt-0.103.0-8.fc19.x86_64
and I haven't experienced anything like your reported problem, nor has anyone in our Bugzilla.
Cheers,
Martin

I've now tried to reproduce the issue with openSUSE factory (to be 13.1), and it still leaks.
Used:
glib2 2.37.4
polkit 0.111
polkit-qt-1 master
KDE workspace 4.10.95/master
Tested with Oliver's example, in ~10min's since the cron job started, kded4 memory increased by 10MB. Stopping the job made kded4 memory at idle.

I've managed to reproduce on my personal laptop with Fedora 19 (and some rawhide bits). Don't know why it didn't prevail in the past, probably just tested wrong.
Will do some debugging on Powerdevil in the evening as it'll be far easier on a physical machine.

Didn't dwell deep into the problem. However, it seems related to brightness control - not only by the messages in the log but also by the fact the leak doesn't occur when I had the displays turned off overnight using 'xset dpms force off'.

I'm running a LiveCD of Linux Mint 14 (Maya) and this bug seems to coincide with screen blanking.  I am running KDE 4.10:
[shellcode]
mint@mint:~ > kde4-config -v
Qt: 4.8.4
KDE Development Platform: 4.10.4
kde4-config: 1.0
[/shellcode]

I finally managed to catch it early enough to still be able to bring up a screen or have responses to my keyboard/mouse (usually I can kiss whatever I'm working on goodbye) and I got the following output on a console where I had re-started kded4 last time.  I wonder if these are the guilty modules:
[shellcode]
"Activation of org.kde.powerdevil.backlighthelper timed out" 
kded(31660) PowerDevilUPowerBackend::setBrightness: org.kde.powerdevil.backlighthelper.setbrightness failed
[/shellcode]

Even after this bug is fixed it really leaves the question of where we fell down in the GNU/Linux+Xorg+KDE architecture such that a thrashing process is capable of bringing your desktop system to a grinding halt like that...

Some additional info as I am also suffering from this:

- KDE 4.11.2, self compiled
- Desktop system (Need power management to switch off the monitors at idle)
  No brightness control available though
- Kernel 3.11.0
- glibc-2.17-13.fc19.x86_64
- polkit-qt-0.103.0-7.fc19.x86_64
- polkit-0.107-5.fc18.x86_64

Can confirm that disabling powerdevil stabilizes memory usage.

I'm also getting hit by this bug.

KDE 4.11.4.

Disabling power management service stops the leak.

4.11.3, same problem for me. When it first starts, kded4 has about 17MB. But slowly it grows in memory usage... at a rate of 200MB per day or so. Killing and starting it again fixes the problem. I haven't tried disabling power management yet, but many suggested it's related.

As a workaround one can periodically restart "powerdevil" service via D-Bus interface (using cron for instance).

DISPLAY=:0 qdbus org.kde.kded /kded unloadModule powerdevil
DISPLAY=:0 qdbus org.kde.kded /kded loadModule powerdevil

To be exact, it's caused by the backlight controller in powerdevil. I haven't found the precise source of the problem though, I'm not even sure if it's in polkit-qt or powerdevil itself...

I was away from home and left my computer running for about 14 days. When I came back, I found kded4 had reached 1.4 GB of memory usage. Although the growth is slow, there seems to be no limit to how far kded4 can leak.

Still the case in 4.11.5, and this doesn't seem marked as resolved for 4.12 either. I don't mean to be pushy, since I know KDE is free software and developers might not have time to look into complex problems very quickly. But this is probably one of the biggest issues to this day, and it's been there for months. Can someone please bump it on their priority list if possible, so maybe a solution can make it to 4.12 at least?

I have the same problem under openSUSE 13.1 x64 with the "radeon" kernel driver. kded4, plasma-desktop, and Xorg all leak memory with continued desktop use. Right now, Xorg is taking about 400 megs of ram, and kded4 is taking 200. When the system boots, all these processes take up a small amount of ram. With continued use, they grow and grow and grow. On a Windows machine, the desktop can be up for weeks with all the processes staying the same size. Shouldn't the same be possible on a KDE desktop without having to log in and log out every day? C'mon guys!

*** Bug 306206 has been marked as a duplicate of this bug. ***

Since a relatively recent update (last 2-3) kded4 have been chewing up my RAM. 
When I just killed it had leaked about 10G of RAM.
I have KDE 4.12.5 under Fedora 20.

(In reply to comment #98)
Wow... good thing my distro is still at 4.11. I really like KDE and what the devs did with it... but I'm disappointed that bugs as big and dangerous as this are still making it into release versions, and actually getting worse rather than getting solved :(

I'm running KDE 4.13.1 now. Needless to say, the leak is still there. But at least not any worse like steve szmidt experienced... still about 100MB per day.

I have experienced this issue also, and I feel I can now say unequivocally this is NOT a KDE specific issue.  I had a very stable KDE (sc 4.13) system with an old Radeon (2600 pro) card running with the open source drivers.  Oddly enough this worked great in KDE, but had a few strange font rendering issues only with GTK applications.  So I got a Nvidia GT 420.  It of course sucked for performance on the nouveau drivers since for a long time they were denied info on how to do reclocking, so I made the mistake of trying the proprietary nvidia driver.  As soon as I did so kded4 began leaking memory like a sieve as reported in this and many prior threads over the years, yes, I would say roughly about 100K per day...

Indeed, as suggested elsewhere in this and past threads, disabling power devil does make this behavior stop.  However, given that Nvidia replaces much of the graphic stack with their own buggy libraries which do seem to have other memory leaks of their own, too, it is clear to me the breakage is on their side.  I am not sure how Nvidia's drivers interact so badly with power management in particular, but I am greatly underwhelmed with them in general, even their most current (331) stack...

This is also not the first time I had seen this behavior with these Nvidia drivers.  There was an older debian machine running KDE at a place I worked at a few years back which had a GT 520 card with the Nvidia drivers of that time which had this very same issue, though I did not have a before-and-after experience with it, and so did not connect it with that at the time.  I also note most who have commented on this and past related threads, and in trying to resolve this issue for my system I read most of them, who said what hardware they were using also noted they were using nvidia.

When a manufacture chooses to provide drivers, but yet do so in a manner that prevents others from fixing them, which always is a very bad ethical choice to begin with, at minimum they clearly then must have a duty to at least do so themselves.  I now fully appreciate why Travolds choose to raise a middle finger to Nvidia...

I meant to say roughly 100 meg per day...

All open-source radeon here.

If there's any chance of NVidia drivers being culprit, there should be a way to generate logs and tracing info to support such claims.
At least it's about the interaction between KDE components and something else, because the NVidia drivers by themselves don't cause such an issue in other environments. I used different flavors of Ubuntu before trying kubuntu and hitting this problem in the first 24 hours of use. In the same nvidia-powered laptop. 

BTW, comment 20 confirmed this bug on a different chipset, so no NVidia drivers for that one. Nevertheless, it would be interesting if two different problems are being found here as a unique problem.

(In reply to comment #98)
> Since a relatively recent update (last 2-3) kded4 have been chewing up my
> RAM. 
> When I just killed it had leaked about 10G of RAM.
> I have KDE 4.12.5 under Fedora 20.

And I'm using nouveau. Though it looks more and more to me that anything connecting to kded4 can cause it.

More eyes here, I suppose:
Please see https://git.reviewboard.kde.org/r/119088/ . There's a patch that probably fixes this. Or at least makes the leak smaller...

*** Bug 337260 has been marked as a duplicate of this bug. ***

So what is missing to get this issue in powerdevil fixed? I can't remove powerdevil because then the suspend function in KDE is gone.

If you need any additional information,  patch testing or further debugging let me know.

(In reply to comment #106)
> More eyes here, I suppose:
> Please see https://git.reviewboard.kde.org/r/119088/ . There's a patch that
> probably fixes this. Or at least makes the leak smaller...

Any ideas how to fix this on 4.11.10?

Have been running 4.14.0 now for a week and the leak seems to be significantly smaller, if not gone altogether. The RES usage of kded4 is now at about 130M. Earlier one week meant >1G RES.

Now at 4.14.2 and have to retract my previous statement:
Ths from "top"

 4779 testuser     20   0 5892492 3,981g  43692 S   0,0 25,6   1:47.04 kded4 

This session on a desktop was just a login and then left unused for 5 days.

So the problem is definitely still there!

Runnung on fedora 20 with selfcompiled KDE.

Hi,

i came across this problem several days ago noticing an inceasing memory usage up to 4gb by kded4. In the last days i watched it more carefully and recognized that sometimes the memory consumption increased by 1gb in several hours.

For me this problem is reproduceable every time. I run several experiments on my pc using 2 python tools ( which can be found here: https://bitbucket.org/db7/dude and here: https://bitbucket.org/db7/muddi). In short what they do: muddi invokes scp/ssh commands on remote pcs, dude writes configuration files.
If i run my experiments with these tools i can watch the memory increasing every time i simply start an experiment and diretly after stop the experiment execution (via ctrl+c). By doing this, i can increases kded4's memory consumption by ~10-20mb each time.

Since this problem occur in my case direct and not over long run times, i did not further check the the running services as suggested here. 

Is there any other information i can provide, that helps finding the problem?

Additional infos: Im using LinuxMint 17 KDE version
Qt: 4.8.6
KDE: 4.13.3

Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
[GCC 4.8.2] on linux2

Created attachment 89553 [details]
Single exit point from PowerDevilUPowerBackend::setBrightness

Hi there!

I noticed a couple of weeks ago that my KDE upgrade to 4.14.2 was incomplete and hadn't upgraded kde-workspace from 4.11.11. I then upgraded that to 4.11.13, but added a patch that created a single exit point out from function PowerDevilUPowerBackend::setBrightness. (Patch attaced)
Never liked functions that exit all over the place. Creates difficulties in debugging and can trick compilers to not free up memory.
Anyway the memory usage has been constant at about 200k/kded-process during the last weeks and so it might have done the trick.... YMMV

(In reply to thomas.peter92 from comment #112)
> Hi,
> 
> i came across this problem several days ago noticing an inceasing memory
> usage up to 4gb by kded4. In the last days i watched it more carefully and
> recognized that sometimes the memory consumption increased by 1gb in several
> hours.
> 
> For me this problem is reproduceable every time. I run several experiments
> on my pc using 2 python tools ( which can be found here:
> https://bitbucket.org/db7/dude and here: https://bitbucket.org/db7/muddi).
> In short what they do: muddi invokes scp/ssh commands on remote pcs, dude
> writes configuration files.
> If i run my experiments with these tools i can watch the memory increasing
> every time i simply start an experiment and diretly after stop the
> experiment execution (via ctrl+c). By doing this, i can increases kded4's
> memory consumption by ~10-20mb each time.
> 
> Since this problem occur in my case direct and not over long run times, i
> did not further check the the running services as suggested here. 
> 
> Is there any other information i can provide, that helps finding the problem?
> 
> Additional infos: Im using LinuxMint 17 KDE version
> Qt: 4.8.6
> KDE: 4.13.3
> 
> Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
> [GCC 4.8.2] on linux2

additional info:
I can increase kded4 memory consumption by simply running an ssh command like:
ssh xxx.xxx.xxx.xx ls -d /tmp/dir 

this increases the memory by ~2mb on the remote machine each time i run that command.

remote machine is a live version of LinuxMint kde and no user logged in (except via ssh)

(In reply to thomas.peter92 from comment #114)
> (In reply to thomas.peter92 from comment #112)
> > Hi,
> > 
> > i came across this problem several days ago noticing an inceasing memory
> > usage up to 4gb by kded4. In the last days i watched it more carefully and
> > recognized that sometimes the memory consumption increased by 1gb in several
> > hours.
> > 
> > For me this problem is reproduceable every time. I run several experiments
> > on my pc using 2 python tools ( which can be found here:
> > https://bitbucket.org/db7/dude and here: https://bitbucket.org/db7/muddi).
> > In short what they do: muddi invokes scp/ssh commands on remote pcs, dude
> > writes configuration files.
> > If i run my experiments with these tools i can watch the memory increasing
> > every time i simply start an experiment and diretly after stop the
> > experiment execution (via ctrl+c). By doing this, i can increases kded4's
> > memory consumption by ~10-20mb each time.
> > 
> > Since this problem occur in my case direct and not over long run times, i
> > did not further check the the running services as suggested here. 
> > 
> > Is there any other information i can provide, that helps finding the problem?
> > 
> > Additional infos: Im using LinuxMint 17 KDE version
> > Qt: 4.8.6
> > KDE: 4.13.3
> > 
> > Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
> > [GCC 4.8.2] on linux2
> 
> additional info:
> I can increase kded4 memory consumption by simply running an ssh command
> like:
> ssh xxx.xxx.xxx.xx ls -d /tmp/dir 
> 
> this increases the memory by ~2mb on the remote machine each time i run that
> command.
> 
> remote machine is a live version of LinuxMint kde and no user logged in
> (except via ssh)

I can confirm this on two (desktop and laptop) installs of openSUSE 13.2 with KDE 4.14.2  from standard openSUSE repos.
$ rpm -qf `which kded4`
kdelibs4-4.14.2-1.1.x86_64

(In reply to thomas.peter92 from comment #114)
> (In reply to thomas.peter92 from comment #112)
> I can increase kded4 memory consumption by simply running an ssh command
> like:
> ssh xxx.xxx.xxx.xx ls -d /tmp/dir 
> 
> this increases the memory by ~2mb on the remote machine each time i run that
> command.

Confirmed on kdelibs-4.14.3-1.fc21.x86_64 (Fedora 21)

$ ssh localhost "echo bye"
 => kded4 RSS+=2MB

:(

I have selected this bug as the "Bug of the Month". See https://community.kde.org/Gardening

If you are able to fix it, you will receive a honorable mention in the next issue of my blog post "The Bug of the Month" on Planet KDE.

Not all developers that would be able to fix it are subscribed to this bug. If you know someone, feel free to point them here.

I think I am dealing with the same bug.  I don't even have to do anything to get it to display itself.  I have two side-by-side computers currently running openSUSE 13.2 and KDE4 with the latest patches.  They are configured so they do not have internet access, so I will not get an unexpected update or access.

I use one of them as an Apache server, the other (presently) as a backup.  Each has 2 GiB of RAM and 2 GiB of swap.  Each exhausts both RAM and swap in a few more than 14 days.  Running "ps axo %mem,pid,euser,cmd | sort -nr | head -n 3" I can watch "kdeinit4: kded4 [kdeinit]" grow from 2% mem to over 70 %mem.

Warning: If you want me to test things, I will need some hand-holding.  For example, an instruction above says to go to "System Settings > Startup and Shutdown > Service Manager"  I have no clue where to find "System Settings."  The Help "life preserver" tells me what it does, but not where to find it.  On the other hand, I have no problem finding the 33 services in /usr/share/kde4/services/kded/ but if I remove an arbitrary subset of them and something dies, I will have no idea what to do (other than run a live DVD and restore them).  I lose patience quickly when I have no idea what I am doing wrong.

Clarification: This bug only tracks kded memory leaks that are related to Power Management. In other words, if you can reproduce ever growing memory usage in kded process with that kded module disabled, please report a new bug stating which module is responsible.

To disable the Power Management module, run "systemsettings" or "kcmshell4 kded", and disable it in Startup and Shutdown > Service Manager > Startup Services. You can also temporarily remove powerdevil.desktop from share/kde4/services/kded/ path. Always restart the session before retesting.

Comment #116 says it is reproducible, but does not state which kded module is responsible.

More instructions at http://kdepepo.wordpress.com/2011/05/11/troubleshooting-kded4-bugs/

Thanks very much for the insight, Christoph.    My report is on the same bug. When Power Management is disabled in systemsettings, memory growth stops.  I believe that disables "powerdevil."  I consider it well-named.  I can imagine it has a very difficult task, since computers may have many different bios methods of handling power in battery-operated configurations. 

I was surprised to learn how many other things were affected by disabling Power Management.  My normal configuration is konsole with 4 tabs and firefox with 4 tabs.  I turned Power Managment off, then rebooted my computers. One is an Athlon 64 - 3400+ in an E-Machine C6207 made in 2005, with a Phoenix Award BIOS, no version id. The other is an Intel Core-2 VPro in a Dell Optiplex 755, BIOS Revision A10.  When the E-Machine came up, the konsole, firefox and even the desktop folder view were all missing.  When the Dell machine came up, the desktop folder view was there, but the konsole and firefox were only on the panel, grayed out. I could not launch them, but I could delete them.  Do you consider this a bug worth reporting? 

My objective is to leave Apache running long-term, and have KDE available when I need to do maintenance or development. Since I am running on vanilla PCs, I would prefer to just shut down Power Manager, but I don't like losing the "desktop restore" after the occasional reboot.

My workaround is to run KDE when I am actively doing work, and use init 3 to kill it when I am not, leaving Apache active.

Hello! 

It seems, that the problem is not in powerdevil, nor in KDE (and it's libraries) at all.
I've found, that policykit-1-0.105 in my Debian Wheezy doesn't release reference counters of GVariant data for org.freedesktop.PolicyKit1.Authority.EnumerateActions dbus call. 

So in my case following patch solves my kded4 with enabled powerdevil extreme memory leak:
--- policykit-1-0.105.orig/src/polkit/polkitauthority.c
+++ policykit-1-0.105/src/polkit/polkitauthority.c
@@ -715,7 +715,6 @@
   while ((child = g_variant_iter_next_value (&iter)) != NULL)
     {
       ret = g_list_prepend (ret, polkit_action_description_new_for_gvariant (child));
-      g_variant_ref_sink (child);
       g_variant_unref (child);
     }
   ret = g_list_reverse (ret);

After removing g_variant_ref_sink(child), rebuilding policykit-1-0.105 packages, their reinstallation and kded4 restart with 'kquitapp kded; kded4' I can't see any memory leak. jemalloc profiling and valgrind confirmed this.

Max, thanks for the investigation and patch!

I will ask distribution maintainers for compiled packages with your patch for testing.

openSUSE users can test polkit package here:

Factory/Tumbleweed:
http://download.opensuse.org/repositories/home:/sumski:/kde271934/openSUSE_Factory/

13.2:
http://download.opensuse.org/repositories/home:/sumski:/kde271934/openSUSE_13.2/

13.1:
http://download.opensuse.org/repositories/home:/sumski:/kde271934/openSUSE_13.1/

installing the opensuse 13.2 package. Will let you know the results in a day or so.

I installed the patched opensuse 13.2 package and ran a a couple of ssh commands:

#!/bin/bash
for i in {1..100}
do
  ssh localhost "echo bye"
done

Without the patch memory usage increases by a couple hundred mega bytes, with the patch no increase at all.

Big thanks to Max for his patch and Hrvoje for the packages.

I can confirm the same on opensuse 13.2

Has this already been reported to polkit upstream?

It's nice that this is pinpointed, but have anyone thought about bad effects from removing that line? I suppose it was there for a reason....

The patch has resolved my openSUSE 13.2 system too.   Nearly 12h and no memory increase.

(In reply to Kevin Kofler from comment #127)
> Has this already been reported to polkit upstream?

https://bugs.freedesktop.org/show_bug.cgi?id=88288

(In reply to dag from comment #128)
> It's nice that this is pinpointed, but have anyone thought about bad effects
> from removing that line? I suppose it was there for a reason....

the patch has been already pushed to polkit git repo, hopefully polkit devs know what they approve ;-)

(In reply to Hrvoje Senjan from comment #130)

> (In reply to dag from comment #128)
> > It's nice that this is pinpointed, but have anyone thought about bad effects
> > from removing that line? I suppose it was there for a reason....
> 
> the patch has been already pushed to polkit git repo, hopefully polkit devs
> know what they approve ;-)

If they are happy, I am happy. A big THANKYOU!

Hi, how silly of me to not say:  a /huge/ thanks for getting the issue resolved.  I very much appreciate it!

Thank you!

Really happy to see this solved... the problem has been bugging me for over an year now! Does anyone know if openSUSE 13.2 will roll this in its update repository? I prefer not using custom repos for important system packages.

yes, updates for both openSUSE 13.1 and 13.2 are pending

Hi!
I also have this bug on kubuntu 14.04 using kde 4.14.2.
I'm glad to see that a solution was found.
Will kubuntu 14.04 incorporate this fix?

(In reply to Luis Lucas from comment #135)
> Hi!
> I also have this bug on kubuntu 14.04 using kde 4.14.2.
> I'm glad to see that a solution was found.
> Will kubuntu 14.04 incorporate this fix?

Same goes to Fedora 21, using kde 4.14.3?

(In reply to Hrvoje Senjan from comment #134)
> yes, updates for both openSUSE 13.1 and 13.2 are pending

fyi, updates are available in standard openSUSE repositories for 13.1, 13.2 & Tumbleweed since sometimes last week

Supposedly the polkit fix was included in 0.112.7, which was updated in Fedora 20 and 21 earlier this month.  However, I'm still experiencing this on Fedora 20 (haven't tried on F21), with polkit-0.112-7.fc20.1.x86_64 and kdelibs-4.14.4-2.fc20.x86_64.  Or at least, something with identical symptoms (bloated, unresponsive kded4).  Doing

    killall -HUP kded4

results in about a minute or so of furious CPU activity (100% of one core), and then either:
    a) things work OK for a while (unlikely); or
    b) kded4 eventually goes away (most common).

What information can I provide to help debug it?  This shows as resolved, should I open a new bug?

Thanks!

Christopher, see comment #119.

Thanks very much, Christoph - somehow I missed that one.

I do not know whether Andres Salcedo is still active, but perhaps someone (Christoph Feck?) could change the bug title from the general
"kded4 process grows on memory usage (possible leak)"
to something reflecting the restriction Christoph has announced:
"kded4 memory leaks related to Power Management"

"Comment 119: Clarification: This bug only tracks kded memory leaks that are related to Power Management. In other words, if you can reproduce ever growing memory usage in kded process with that kded module disabled, please report a new bug stating which module is responsible."  (Christoph Feck)

Sorry for the long delay in getting back on this.  In the interim, though, I updated to kdelibs 4.14.6 and the memory leak is no longer occurring.  I'm not sure whether it was actually fixed, or just masked by another change, but it's no longer reproducible.