Bug 312092 - kded4 memory leak - RAM use is very high - dead battery is trigger
Summary: kded4 memory leak - RAM use is very high - dead battery is trigger
Status: RESOLVED UNMAINTAINED
Alias: None
Product: solid
Classification: Unclassified
Component: powermanagement-daemon (show other bugs)
Version: 4.9.3
Platform: Ubuntu Packages Linux
: NOR grave (vote)
Target Milestone: ---
Assignee: Dario Freddi
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-23 02:04 UTC by kdebugs
Modified: 2018-09-04 15:46 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
good battery results (1.24 KB, text/plain)
2013-04-26 18:24 UTC, kdebugs
Details
bad battery results (1.27 KB, text/plain)
2013-04-26 18:24 UTC, kdebugs
Details
stderr console output of kded4 after kdebugdialog settings tweaked (13.95 KB, text/plain)
2013-10-18 21:37 UTC, kdebugs
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kdebugs 2012-12-23 02:04:04 UTC
I noticed significant slowness due to swap use, etc. RAM use is maxed out, and I notice that kded4 is using >700MB of RAM. I assume this is a leak:

$ ps -FC kded4
UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
casey     2148     1  1 402048 755716 0 14:59 ?        00:01:47 kdeinit4: kded4 [kdeinit]

This started maybe yesterday (haven't noticed it 'till then), so it might have been a recent update that did it.

I am current with Kubuntu repository packages.

Rebooting resets the memory use. I am still checking to see how the growth happens (e.g. all at once, gradually, associated with any particular actions, etc.) It seems to continue and get larger and make the computer unusable.


Reproducible: Always

Steps to Reproduce:
1. boot up
2. observe that memory footprint is low
3. use the computer a while
4. observe that memory footprint is high
5. eventually rebooting is necessary




$ uname -a
Linux caseylinux 3.5.0-21-generic #32-Ubuntu SMP Tue Dec 11 18:52:46 UTC 2012 i686 i686 i686 GNU/Linux

Kubuntu 12.10 on a Dell Inspiron 6000. I have many features disabled/turned off (no desktop effects, no akonadi, no nepomuk, etc etc.)

Happy to provide more info.
Comment 1 kdebugs 2012-12-23 03:18:51 UTC
Figured something out:

I have two dead batteries. One is not recognized at all by the system and shows as "battery disconnected" when the computer is on. The other is dead (always 0% charge), but does show up. 

When the recognized 0% charge battery is installed, I see something running every 10 seconds. Every time it runs, ~1 MB of memory is added to the total system use, and it just gradually rises. This seems to be the trigger of the issue.

When I have the other, unrecognized battery in, or no battery installed at all, this problem goes away. Presumably a healthy battery would also be OK, but I don't have one right now. :-)

I used a script to track diffs in the process list, but whatever is happening every 10 seconds doesn't seem to be an independent process or thread.

Let me know what else I can do to help track this down.
Comment 2 kdebugs 2012-12-23 04:17:22 UTC
Correction: "doesn't seem to be an independent process or thread" ...or is so short lived that it was not caught by ps when the script runs it.
Comment 3 Oliver Henshaw 2013-02-27 18:30:40 UTC
Bug #294497 is vaguely similar (memory leak perhaps linked to malfunctioning battery, but memory only increases every suspend/resume cycle). Some commenters report that this is no longer a problem on ubuntu 12.10 + updates(?).

Are you still seeing this?
Comment 4 Alex Fiestas 2013-03-03 17:49:10 UTC
Can anybody answer to Oliver question?

Thanks !
Comment 5 kdebugs 2013-03-04 03:29:06 UTC
Hello - yes the problem is still happening. 12.10 with latest updates. Let me know if I can provide any other information.

-c
Comment 6 Alex Fiestas 2013-03-05 21:08:08 UTC
Can you try if unloading powerdevil fixes this? basically go to:
System Settings ---> Startup and Shutdown --> Service Manager 

Then look for "Power Management" and Stop it (or uncheck it to disable it from auto booting).

Then try to reproduce the leak.

If it still happens it means that PowerDevil is not to blame, if it stops happening then we should look further at what is happening.

Thanks !
Comment 7 kdebugs 2013-03-05 21:56:47 UTC
Confirmed that disabling "Power Management" stops the problem. When I rebooted, memory was stable and the small spikes in CPU went away.

When I started the service again, memory again started to climb in sync with the small spikes in CPU.

Thanks,
-c
Comment 8 Oliver Henshaw 2013-03-12 17:29:20 UTC
Running kded under massif[1] might be interesting.

[1]  http://valgrind.org/docs/manual/ms-manual.html
Comment 9 kdebugs 2013-03-12 21:18:39 UTC
I have discovered Bug #271934 (https://bugs.kde.org/show_bug.cgi?id=271934). It sounds like exactly the same issue. Status is resolved/fixed, but comments at end (and my experience) imply that it is not.

There are some massif logs in that bug thread... do you still want one from me?

If so -- massif seems pretty straightforward to use, but compiling and swapping kded would be my confusion point. Any tutorial/guide links for that?

Thanks,
-c
Comment 10 Oliver Henshaw 2013-03-12 22:59:42 UTC
Good find. I only see --memcheck logs there, not --massif output. Massif is useful because it will log memory increases that aren't strictly memory leaks.

I'm not sure what you mean about "compiling and swapping kded": you should just be able to install debuginfo packages for kde-workspace (and its dependenciesn ) - your distribution should have a mechanism for this. Then you can restart kded4 with 'pkill kded4; valgrind --tool=massif kded4' and let it run for a while until memory use has increased noticeably.

I've found "-time-unit=ms --max-snapshots=1000" useful arguments to massif but can't remember exactly why - maybe because otherwise most snapshots are from startup (or something like that?) - I haven't used massif in a while but I'm sure it will come back to me...
Comment 11 kdebugs 2013-03-13 08:05:30 UTC
Ok, I'll do that and report back, thanks.

After the profiling has run for a while and I want to get kded4 back to normal, do I pkill kded4 again and then run just plain "kded4", or is there some more proper way to stop the profiling?

I assume that when we're done I can remove the installed debuginfo packages and that will cleanly put things "back to normal".

re: compile/swap: I was confused by the massif tutorial which says "you should compile with debugging info (the -g option)", so I thought I had to compile kded4 and swap the binary out. Nice to know there's an easier way.
Comment 12 kdebugs 2013-03-14 01:34:18 UTC
Ok - I did the following:

- put bad battery in (which triggers all this)
- start up computer
- wait 'till stable desktop after boot
- kill kded4
- run it with valgrind/massif

...and, the probelm stops. Meaning, no periodic CPU spikes that result in memory gain. Flat memory use over a half hour or so.

- kill valgrind/kded4 process
- run kded4 again

...and, the problem is immediately back. So i can't seem to capture it with massif while it's happening.

Maybe a race condition that is not triggered when kded4 is running in slow-mo under valgrind? Some other reason that kded4 would behave differently under valgrind? I'm running these processes as my username, not root.

I can provide the massif logs, but it seemed like they wouldn't be useful for now. (Tried running valgrind with and without the max-snapshots option, btw.)

So... other ideas on how to catch kded4 in the act?

Thanks!
Comment 13 Oliver Henshaw 2013-03-14 20:50:38 UTC
(In reply to comment #11)
> After the profiling has run for a while and I want to get kded4 back to
> normal, do I pkill kded4 again and then run just plain "kded4", or is there
> some more proper way to stop the profiling?
Yep, that should work.

> I assume that when we're done I can remove the installed debuginfo packages
> and that will cleanly put things "back to normal".
Yep, except the only cost to debuginfo packages is space on disk and probably time spent updating them in the future. They don't cost anything at runtime unless they're being used - they're an addition to the normal packages, not a replacement.

> re: compile/swap: I was confused by the massif tutorial which says "you
> should compile with debugging info (the -g option)", so I thought I had to
> compile kded4 and swap the binary out. Nice to know there's an easier way.
I think that's for people who roll everything themselves. Your distribution should be taking care of these kinds of details for you.

(In reply to comment #12)
> Ok - I did the following:
> 
> - put bad battery in (which triggers all this)
> - start up computer
> - wait 'till stable desktop after boot
> - kill kded4
> - run it with valgrind/massif
> 
> ...and, the probelm stops. Meaning, no periodic CPU spikes that result in
> memory gain. Flat memory use over a half hour or so.
> 
> - kill valgrind/kded4 process
> - run kded4 again
That is odd. If you kill kded4 and restart it (without valgrind) a few times does the memory rise happen every time?

> So... other ideas on how to catch kded4 in the act?
It might be interesting to see the output of both of:

$ dbus-monitor --session "interface='org.kde.Solid.PowerManagement'"
$ dbus-monitor --system "interface='org.freedesktop.UPower'"

and see if there are any clues there.
Comment 14 kdebugs 2013-03-15 02:21:51 UTC
> the only cost to debuginfo packages is space on disk and probably time spent updating them in the future.

Thanks - all good to know. I am in fact really tight on space on /, had to clear a bunch of stuff of to install them, so i will remove them later.

> If you kill kded4 and restart it (without valgrind) a few times does the memory rise
> happen every time?

Yes. So far, 100% of the time that the following three conditions are satisfied, the pattern happens:

- dead battery installed
- kded4 running
- kded4 not running under valgrind/massif

I can swap a battery in and out, kill/start kded4, etc.

> It might be interesting to see the output of both of: $ dbus-monitor

Maybe something here -- the UPower dbus shows one of the following lines in sync every time the spike/memory increase happens:

signal sender=:1.29 -> dest=(null destination) serial=4195 path=/org/freedesktop/UPower; interface=org.freedesktop.UPower; member=DeviceChanged
   string "/org/freedesktop/UPower/devices/battery_BAT0"
signal sender=:1.29 -> dest=(null destination) serial=4204 path=/org/freedesktop/UPower; interface=org.freedesktop.UPower; member=DeviceChanged
   string "/org/freedesktop/UPower/devices/battery_BAT0"
signal sender=:1.29 -> dest=(null destination) serial=4213 path=/org/freedesktop/UPower; interface=org.freedesktop.UPower; member=DeviceChanged
   string "/org/freedesktop/UPower/devices/battery_BAT0"
signal sender=:1.29 -> dest=(null destination) serial=4222 path=/org/freedesktop/UPower; interface=org.freedesktop.UPower; member=DeviceChanged
   string "/org/freedesktop/UPower/devices/battery_BAT0"
signal sender=:1.29 -> dest=(null destination) serial=4231 path=/org/freedesktop/UPower; interface=org.freedesktop.UPower; member=DeviceChanged
   string "/org/freedesktop/UPower/devices/battery_BAT0"
signal sender=:1.29 -> dest=(null destination) serial=4240 path=/org/freedesktop/UPower; interface=org.freedesktop.UPower; member=DeviceChanged
   string "/org/freedesktop/UPower/devices/battery_BAT0"
Comment 15 kdebugs 2013-03-15 02:22:13 UTC
(the other dbus command showed nothing, btw)
Comment 16 Oliver Henshaw 2013-03-21 14:11:33 UTC
Maybe it's timing dependent like you said, or maybe massif uses different memory allocators - would that suggest that the problem is fragmentation? I'm not sure.

(In reply to comment #14)
> Maybe something here -- the UPower dbus shows one of the following lines in
> sync every time the spike/memory increase happens:
> 
> signal sender=:1.29 -> dest=(null destination) serial=4195
> path=/org/freedesktop/UPower; interface=org.freedesktop.UPower;
> member=DeviceChanged
>    string "/org/freedesktop/UPower/devices/battery_BAT0"

I can't see anything we do in response to this signal that looks suspicious, but maybe I'm just not looking hard enough. Though the solid device interface in kdelibs looks pretty complicated.

Does the memory go away if you unload the powerdevil module, once it has started to rise?

It would be useful to know what properties of the battery are changing - I think 'upower --monitor-details' should tell us that. Can you run that for a few tens of seconds (enough that you get a few rounds of updates)?
Comment 17 kdebugs 2013-03-25 07:25:47 UTC
> Does the memory go away if you unload the powerdevil module, once it has
> started to rise?

Like this?:

$ qdbus org.kde.kded /kded unloadModule powerdevil

...didn't seem to have any effect on the already-increased memory use. (Killing kded4 seems to free the memory, but my test period wasn't very long... Let me know if you want better confirmation, but my memory of past tests is also that it frees the memory.)

> It would be useful to know what properties of the battery are changing - I
> think 'upower --monitor-details' should tell us that. Can you run that for a
> few tens of seconds (enough that you get a few rounds of updates)?

upower --monitor-details just returns immediately with no output (as me or as root). Bug in upower? But --monitor shows this, for whatever it's worth:

$ upower --monitor
Monitoring activity from the power daemon. Press Ctrl+C to cancel.
[00:19:39.917]  device changed:     /org/freedesktop/UPower/devices/battery_BAT0
[00:19:50.112]  device changed:     /org/freedesktop/UPower/devices/battery_BAT0
[00:20:00.305]  device changed:     /org/freedesktop/UPower/devices/battery_BAT0
[00:20:10.504]  device changed:     /org/freedesktop/UPower/devices/battery_BAT0
[00:20:20.700]  device changed:     /org/freedesktop/UPower/devices/battery_BAT0
[00:20:30.894]  device changed:     /org/freedesktop/UPower/devices/battery_BAT0
[00:20:41.092]  device changed:     /org/freedesktop/UPower/devices/battery_BAT0

And in case this is interesting:

$ upower --dump
Device: /org/freedesktop/UPower/devices/line_power_AC
  native-path:          /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/AC
  power supply:         yes
  updated:              Sun Mar 24 21:28:58 2013 (10097 seconds ago)
  has history:          no
  has statistics:       no
  line-power
    online:             yes

Device: /org/freedesktop/UPower/devices/battery_BAT0
  native-path:          /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0
  vendor:               Sony
  model:                DELL UY4366
  serial:               50250
  power supply:         yes
  updated:              Mon Mar 25 00:17:06 2013 (9 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               charging
    energy:              0 Wh
    energy-empty:        0 Wh
    energy-full:         0 Wh
    energy-full-design:  0 Wh
    energy-rate:         0 W
    voltage:             6.896 V
    percentage:          0%
    capacity:            100%
    technology:          lithium-ion

Daemon:
  daemon-version:  0.9.17
  can-suspend:     yes
  can-hibernate    no
  on-battery:      no
  on-low-battery:  no
  lid-is-closed:   no
  lid-is-present:  yes
  is-docked:       yes
Comment 18 Oliver Henshaw 2013-04-04 17:45:53 UTC
(In reply to comment #17) 
> upower --monitor-details just returns immediately with no output (as me or
> as root). Bug in upower? But --monitor shows this, for whatever it's worth:
Sorry, that should have been "upower --monitor-detail" - check the upower man page in case I've typoed again.
Comment 19 kdebugs 2013-04-06 01:47:48 UTC
Ah, thanks. Bummer that upower just returns with no error. Anyway, here's the result... they're all the same except for small fluctuations in voltage and the updated timestamp...

-----------------

$ sudo upower --monitor-detail

Monitoring activity from the power daemon. Press Ctrl+C to cancel.
[18:45:18.676]	device changed:     /org/freedesktop/UPower/devices/battery_BAT0
  native-path:          /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0
  vendor:               Sony
  model:                DELL UY4366
  serial:               50250
  power supply:         yes
  updated:              Fri Apr  5 18:45:18 2013 (0 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               charging
    energy:              0 Wh
    energy-empty:        0 Wh
    energy-full:         0 Wh
    energy-full-design:  0 Wh
    energy-rate:         0 W
    voltage:             6.908 V
    percentage:          0%
    capacity:            100%
    technology:          lithium-ion

[18:45:28.872]	device changed:     /org/freedesktop/UPower/devices/battery_BAT0
  native-path:          /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0
  vendor:               Sony
  model:                DELL UY4366
  serial:               50250
  power supply:         yes
  updated:              Fri Apr  5 18:45:28 2013 (0 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               charging
    energy:              0 Wh
    energy-empty:        0 Wh
    energy-full:         0 Wh
    energy-full-design:  0 Wh
    energy-rate:         0 W
    voltage:             6.908 V
    percentage:          0%
    capacity:            100%
    technology:          lithium-ion

[18:45:39.073]	device changed:     /org/freedesktop/UPower/devices/battery_BAT0
  native-path:          /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0
  vendor:               Sony
  model:                DELL UY4366
  serial:               50250
  power supply:         yes
  updated:              Fri Apr  5 18:45:39 2013 (0 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               charging
    energy:              0 Wh
    energy-empty:        0 Wh
    energy-full:         0 Wh
    energy-full-design:  0 Wh
    energy-rate:         0 W
    voltage:             6.908 V
    percentage:          0%
    capacity:            100%
    technology:          lithium-ion

[18:45:49.261]	device changed:     /org/freedesktop/UPower/devices/battery_BAT0
  native-path:          /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0
  vendor:               Sony
  model:                DELL UY4366
  serial:               50250
  power supply:         yes
  updated:              Fri Apr  5 18:45:49 2013 (0 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               charging
    energy:              0 Wh
    energy-empty:        0 Wh
    energy-full:         0 Wh
    energy-full-design:  0 Wh
    energy-rate:         0 W
    voltage:             6.908 V
    percentage:          0%
    capacity:            100%
    technology:          lithium-ion

[18:45:59.460]	device changed:     /org/freedesktop/UPower/devices/battery_BAT0
  native-path:          /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0
  vendor:               Sony
  model:                DELL UY4366
  serial:               50250
  power supply:         yes
  updated:              Fri Apr  5 18:45:59 2013 (0 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               charging
    energy:              0 Wh
    energy-empty:        0 Wh
    energy-full:         0 Wh
    energy-full-design:  0 Wh
    energy-rate:         0 W
    voltage:             6.907 V
    percentage:          0%
    capacity:            100%
    technology:          lithium-ion
Comment 20 Oliver Henshaw 2013-04-14 15:42:48 UTC
Sort of a long-shot, but can you try and capture what the battery is doing with umockdev - https://github.com/martinpitt/umockdev - it looks like 'umockdev-record  /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0 > battery.umockdev' should get you a file you can attach here.

Then in theory we can replay the umockdev record and hopefully reproduce the memory increase. I've never tried to use umockdev, but this looks like the kind of thing it was designed for.
Comment 21 kdebugs 2013-04-18 19:21:55 UTC
I'm trying to give it a shot, but I don't know how to compile umockdev... (couldn't find a package in the repo?)

I cloned the git repo, and I presume that I use "autogen.sh", which complained of a missing autoreconf, so I installed the autoconf2.13 package (which installed autoconf as well as a few other packages). Then I ran autogen.sh again and I get this:

$ ./autogen.sh 
gtk-doc not installed, you will not be able to generate documentation.
Can't exec "libtoolize": No such file or directory at /usr/bin/autoreconf2.50 line 195.
Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf2.50 line 195.
configure.ac:34: installing `build-aux/ar-lib'
configure.ac:33: installing `build-aux/compile'
configure.ac:32: installing `build-aux/install-sh'
configure.ac:32: installing `build-aux/missing'
Makefile.am:24: Libtool library used but `LIBTOOL' is undefined
Makefile.am:24:   The usual way to define `LIBTOOL' is to add `LT_INIT'
Makefile.am:24:   to `configure.ac' and run `aclocal' and `autoconf' again.
Makefile.am:24:   If `LT_INIT' is in `configure.ac', make sure
Makefile.am:24:   its definition is in aclocal's search path.
Makefile.am: installing `build-aux/depcomp'
autoreconf2.50: automake failed with exit status: 1

...I looked around for how to get "libtoolize" but thoguht I would stop doing damage and check in about the best course of action. :-)

Thanks for any tips.
Comment 22 Oliver Henshaw 2013-04-26 14:06:49 UTC
Maybe you need the libtool package?  Anyway, there seems to be ubuntu packages at https://code.launchpad.net/~pitti/+archive/daily-builds
Comment 23 kdebugs 2013-04-26 18:24:16 UTC
Created attachment 79474 [details]
good battery results
Comment 24 kdebugs 2013-04-26 18:24:51 UTC
Created attachment 79475 [details]
bad battery results
Comment 25 kdebugs 2013-04-26 18:25:55 UTC
From the umockd docs, it looks like "umockdev-record" on a battery just records the /sys/devices info and returns (as opposed to recording anything on an ongoing basis), which is what happens when i run it. Attached above are good_battery and bad_battery.umockdev, one for the funcitonal battery and one for the bad one.

Also, here is the diff between those two files, in case it's handy:

$ diff good_battery.umockdev bad_battery.umockdev 
2,4c2,5
< E: POWER_SUPPLY_CHARGE_FULL=6107000
< E: POWER_SUPPLY_CHARGE_FULL_DESIGN=6600000
< E: POWER_SUPPLY_CHARGE_NOW=6038000
---
> E: POWER_SUPPLY_CHARGE_FULL=0
> E: POWER_SUPPLY_CHARGE_FULL_DESIGN=0
> E: POWER_SUPPLY_CHARGE_NOW=0
> E: POWER_SUPPLY_CURRENT_NOW=1000
6,7c7,8
< E: POWER_SUPPLY_MANUFACTURER=Sanyo
< E: POWER_SUPPLY_MODEL_NAME=DELL 00
---
> E: POWER_SUPPLY_MANUFACTURER=Sony
> E: POWER_SUPPLY_MODEL_NAME=DELL UY4366
10c11
< E: POWER_SUPPLY_SERIAL_NUMBER=15
---
> E: POWER_SUPPLY_SERIAL_NUMBER=50250
14c15
< E: POWER_SUPPLY_VOLTAGE_NOW=12557000
---
> E: POWER_SUPPLY_VOLTAGE_NOW=6851000
17,19c18,21
< A: charge_full=6107000
< A: charge_full_design=6600000
< A: charge_now=6038000
---
> A: charge_full=0
> A: charge_full_design=0
> A: charge_now=0
> A: current_now=1000
21,22c23,24
< A: manufacturer=Sanyo
< A: model_name=DELL 00
---
> A: manufacturer=Sony
> A: model_name=DELL UY4366
24c26
< A: serial_number=15
---
> A: serial_number=50250
29c31
< A: voltage_now=12557000
---
> A: voltage_now=6851000
Comment 26 kdebugs 2013-06-10 21:03:11 UTC
So, have we reached the end of line on testing this? :-) If so, I'll be upgrading my system, recycling the old battery, etc. If not, happy to hold on to it and do more experiments.

Thanks,
-c
Comment 27 Alex Fiestas 2013-07-29 16:33:07 UTC
Nooo! please keep it if you can, if we lose our main testcase we won't be able to fix this :/
Comment 28 Alex Fiestas 2013-07-29 16:37:35 UTC
Can you please provide the following:

1-kdebugdialog and enable everythign with "kded" on it
2-restart kded on a terminal
3-provide output

I'm thinking that maybe a suspend job is being triggered and leaked, that might confirm it.
Comment 29 Alex Fiestas 2013-07-29 16:44:05 UTC
Also, with your healthy battery, do you get notifications such "Battery Critical your battery level is critical the computer will be bl;abalblaal" ?

Do you have all "Power Management" notifications enabled? you can check them in systemsettings->notifications ?

Thanks !
Comment 30 kdebugs 2013-08-08 07:00:28 UTC
Hi - I do still have the laptop and battery. Unfortunately i can't debug right now due to busyness, and i'll be on the road for a few weeks here, so i'll check back in after that with responses to your questions (probably mid-Sep). Thanks, -c
Comment 31 kdebugs 2013-10-18 21:32:07 UTC
Hi - I'm back.

Under system settings -> "application and system notifications" -> "notifications for KDE power management system", I do have (and have had) the various notifications enabled. I do not receive any such notifications, however.

I ran kdebugdialog, disabled all, entered "kde" in the search, enabled all those, hit 'apply' and 'ok'. The dialog closes. I run "pkill kded4" and "kded4" (as my standard user, not root). Next I will post the stderr output of that (stdout seemed empty). I let it run for a few of the CPU-spike cycles, but nothing was being output when those happened.
Comment 32 kdebugs 2013-10-18 21:37:38 UTC
Created attachment 82939 [details]
stderr console output of kded4 after kdebugdialog settings tweaked
Comment 33 Andrew Crouthamel 2018-09-04 15:46:57 UTC
Hello! Sorry to be the bearer of bad news, but this project has been unmaintained for many years so I am closing this bug. Please try again with the latest version and submit a new bug to frameworks-solid if your issue persists. Thank you!