awesome-wm-widgets
awesome-wm-widgets copied to clipboard
streetturtle
Memory Leak
I love the widgets, but have noticed a memory leak in the volume, brightness, and battery widgets. I see the leak on my desktop at work (which runs the unmodified volume widget code from the repository on an Antergos base) and on my laptop (which runs slightly modified versions of the volume and brightness widgets: it's an ARM chip running ArchLinuxARM (v7), so I cat the relevant file for the brightness and don't use pulse for the volume, but the battery widget is unchanged.)
I found the leak on the desktop system when getting a 'failed to allocate' error on trying to start a new instance of something, then tracking memory via htop; this showed a fairly steady leak (~500k/sec, if I'm reading htop right). I ruled out as much as I could, then finally decided to try disabling the volume widget; AwesomeWM memory use returned to stable. I then checked and repeated the same on the laptop, checking each widget individually. The leaks on the brightness and volume widgets are pretty much the same, though the battery widget seems to leak only slowly---I didn't even notice it at first.
Anyone else notice something similar, or have any idea how to fix it?
Hi! Thanks for raising an issue. Do you think it could be somehow related to startup notifications (like it this PR)?
I've checked those widgets and all of them are using watch class. Then I realised that I was using it the wrong way. Could you please validate if this commit (Possible fix for memory leak issue #11) solves the issue and let us (me) know.
The recent changes slowed the leak (by a factor of 2 or 3), but there is still a slow leak. Edit: confirmed on the desktop, too. :(
I seem to have the same leak. Maybe 500 kb/s eats up to 20% of my ram, then the volume widget does not longer work.
I updated to the new version (30 May 2017) but still notice the small leak---about 500kb/s like the previous poster.
I tried it again today with a unmodified, updated version of the file. Leak is still there. It starts after the first interaction (raise/lower volume), leaks about 20 MB of memory, then stops. After the next interaction, leakage starts again. Leakage speeds up if you keep scrolling vol up/down even if volume is at max/min level.
How do you detect a memory leak? I'd like to try to make few changes but unfortunately don't know how to detect a memory leak. Also would be nice to check other widgets, maybe problem is in the awful.spawn or in the amixer.
I found the leak with htop, but top should work just as well. If you are not familiar (and you probably are... :D ) both are terminal-style system monitors that update the condition of your processes pretty regularly. When I'm using the widgets, the memory used by the 'awesome' process ticks up gradually; when I comment them out and restart, the memory used by the process is stable. I am not really sure how to check it directly, though I suspect there is a way for those with more linux-fu than I.
Ok, thanks! Actually I tried htop, but was to lazy to play with parameters and comment out all widgets I'm using right now. I'll try to find some kind of Lua profiler or will play with htop and will let you know.
An easy way to monitor is just do "top|grep awesome" it will just post the awesome line each second so you can easily follow what is happening.
Nope... Seems like I don't have this issue, I've been monitoring output of the top | grep awesome and VIRT, RES and %MEM stay at the same level all the time... Probably we need some Lua expert here... =)
no lua expert here, but i also noticed the memory leak. see steady increase of virt:
tim@adm-121865:~$ top | grep awesome
1255 tim 20 0 2603608 2.053g 16032 R 13.3 13.3 87:09.90 awesome
1255 tim 20 0 2604268 2.054g 16032 R 21.3 13.3 87:10.54 awesome
1255 tim 20 0 2604668 2.054g 16032 R 19.9 13.3 87:11.14 awesome
1255 tim 20 0 2605064 2.055g 16032 S 24.6 13.3 87:11.88 awesome
1255 tim 20 0 2605328 2.055g 16032 S 19.6 13.3 87:12.47 awesome
1255 tim 20 0 2605724 2.055g 16032 S 18.9 13.3 87:13.04 awesome
1255 tim 20 0 2605988 2.056g 16032 S 19.9 13.3 87:13.64 awesome
1255 tim 20 0 2606384 2.056g 16032 S 22.5 13.3 87:14.32 awesome
6088 tim 20 0 4 4 0 R 1.0 0.0 0:00.03 awesome
1255 tim 20 0 2606780 2.057g 16032 S 23.3 13.3 87:15.02 awesome
1255 tim 20 0 2607044 2.057g 16032 S 18.6 13.3 87:15.58 awesome
1255 tim 20 0 2607444 2.057g 16032 S 24.8 13.3 87:16.33 awesome
1255 tim 20 0 2607708 2.057g 16032 S 19.9 13.3 87:16.93 awesome
1255 tim 20 0 2608104 2.058g 16032 S 19.3 13.3 87:17.51 awesome
1255 tim 20 0 2608368 2.058g 16032 S 20.3 13.3 87:18.12 awesome
1255 tim 20 0 2609028 2.059g 16032 R 24.9 13.3 87:18.87 awesome
Could somebody check if the latest commit fixed the leak? I did few fixes there which could fix the leak. But now to add a widget in rc.lua it should be explicitly defined in 'require' section
local battery_widget = require("awesome-wm-widgets.battery-widget.battery")
and then used as always:
...
s.mytasklist, -- Middle widget
{ -- Right widgets
layout = wibox.layout.fixed.horizontal,
mykeyboardlayout,
wibox.widget.systray(),
battery_widget,
mytextclock,
s.mylayoutbox,
},
...
If it works I'll update other widgets.
Preliminary tests on my laptop seem to indicate that the memory leak in the battery widget may be fixed, but it was actually the one that leaked the least. I had some increase in the virt for the awesome process at the beginning (when I was still launching programs), and there was some increase as I switched workspaces, but I let it sit for about 25 minutes and didn't notice any change (until I started switching workspaces again---probably normal behavior).
As a suggestion, you might try the volume or brightness widget next as they seemed to be leaking the worst.
Thanks for your efforts! I wish I knew more so I could help! :D
Could you please check now, after e6c3059 commit.
Widgets should be added the same way as I mentioned above:
local battery_widget = require("awesome-wm-widgets.battery-widget.battery")
local batteryarc_widget = require("awesome-wm-widgets.batteryarc-widget.batteryarc")
local brightness_widget = require("awesome-wm-widgets.brightness-widget.brightness")
local volume_widget = require("awesome-wm-widgets.volume-widget.volume")
local volumebar_widget = require("awesome-wm-widgets.volumebar-widget.volumebar")
local volumearc_widget = require("awesome-wm-widgets.volumearc-widget.volumearc")
Please let us know if it helps.
Laptop---
--battery: looking carefully, there seems to still be a leak of about 20 bytes per 5 seconds.
--batteryarc: initial testing led to an error, and I haven't tracked it down yet.
--brightness: the laptop has an ARM processor, so I could not use light or xbacklight either one---I just had it cat the appropriate /sys file, and that seemed to lead to a leak, but that may be a problem with my kludge, not the widget.
---volume, volumebar, volumearc: as far as I can tell, these are rock-steady. :D
Preliminary tests on the desktop (non-battery widgets) show leaks, but I will have to get some time later to post the details.
I am using the volume widget and I still encounter the memory leaks unfortunately
I am using the cpu widget and get the memory leaks.The memory limit to 170MB.
I also have memory leaks in the battery, spottily, and volume widgets.
I notice that the visual responsiveness of scrolling the volume widget seems to degrade as the memory leak goes on. I wonder if that might indicate the leak is originating somewhere in the update_graphic function?
I think I'll try stubbing that function out and running the widget overnight to see what happens :crossed_fingers:
Nope, memory still leaks even with a stubbed function! I dug a little deeper and found this, which is a more likely culprit.
As you can see here, we're using awful.widget.watch to update the visual display, which is implemented via the leaky function.
I wonder if it's possible to bypass the issue for now by implementing our own async timer?