| Summary: | kded4 memory leak - RAM use is very high - dead battery is trigger | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] solid | Reporter: | kdebugs |
| Component: | powermanagement-daemon | Assignee: | Dario Freddi <drf> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | grave | CC: | afiestas, cfeck, kdebugs, oliver.henshaw |
| Priority: | NOR | ||
| Version: | 4.9.3 | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Attachments: |
good battery results
bad battery results stderr console output of kded4 after kdebugdialog settings tweaked |
||
|
Description
kdebugs
2012-12-23 02:04:04 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. 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. 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? Can anybody answer to Oliver question? Thanks ! Hello - yes the problem is still happening. 12.10 with latest updates. Let me know if I can provide any other information. -c 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 ! 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 Running kded under massif[1] might be interesting. [1] http://valgrind.org/docs/manual/ms-manual.html 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 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... 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. 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! (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. > 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" (the other dbus command showed nothing, btw) 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)? > 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 (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. 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
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. 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. Maybe you need the libtool package? Anyway, there seems to be ubuntu packages at https://code.launchpad.net/~pitti/+archive/daily-builds Created attachment 79474 [details]
good battery results
Created attachment 79475 [details]
bad battery results
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 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 Nooo! please keep it if you can, if we lose our main testcase we won't be able to fix this :/ 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. 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 ! 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 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. Created attachment 82939 [details]
stderr console output of kded4 after kdebugdialog settings tweaked
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! |