Open Hacksign opened 10 years ago
Thanks for the feedback! What exactly do you mean by "switch applications fast, and repeat many times"? Is that repeatedly (Alt + Tab -> Release)? Could you check what happens if you put a "collectgarbage()" just before the "keygrabber.stop()" call (line 421 in my version)?
On second thought, the "collectgarbage()" should be placed at the start of the "switch()" function, line 285. Could you try this and see if the problem persists? Thanks! :-)
Thanks for reply. Alt + Tab -> hold Alt,release Tab,then my 2Gb RAM fulled after about 20 seconds.I added collectgarbage() on line 285,just below switch() function.But I received an error "attempt to call global 'collectgarbage'".Dont know much about lua,could u tell me what parameter should I inovke with ?
when I comment line 364 'preview_live_timer:start()' there is no leak.Perhaps It's the live preview function caused the leak ?
Ah, sorry. The "collectgarbage()" call should work when you add "local collectgarbage = collectgarbage" at the top of the file (there are similar statements there). I'll look into your second remark now.
Are you using the preview window at all? Are you using default settings or have you modified them?
Add collectgarbage didnt solve the problem.And I have no extra configuration.Just did as your README document said.It seems static window,like vim,could also cause memory leak.Just open multi window,press alt+tab and hold for seconds,the leak happens.
That's strange... I'm not able to reproduce this problem here. What happens if you watch "top" while this happens? If I do that, the memory usage of awesome remains constant:
Here is my situation,you can check my awesome configu at https://github.com/Hacksign/configs/tree/master/.config/awesome
I honestly have no idea what's happening. Maybe you're running a different Lua version? Could you post your output of "awesome --version"? I can post these findings on the mailing-list. Hopefully someone will have something to say on this...
My setup: $ awesome --version awesome v3.5.5 (Kansas City Shuffle) • Build: Jun 11 2014 02:21:37 for x86_64 by gcc version 4.9.0 (root@miyumi) • Compiled against Lua 5.1.5 (running with Lua 5.1) • D-Bus support: ✔
One other thing you could try.... You said that if you comment the timer-start call, the leak doesn't occur. This timer you mentioned, is responsible for updating the previews. Every time it times out, it sends a widget::updated signal out, which causes the wibox (the box in which the previews are drawn) to be redrawn by cairo. What you could try is change the framerate (currently 30fps) by adding this to your rc.lua: alttab.settings.preview_box_fps = 10 -- or whatever value you want
If the problem is due to the preview-box being redrawn, your memory should last 3 times longer now. It's not a solution, but it is a way to narrow it down.
Btw, for some reason, the change in FPS only takes effect the second-time you Alt-Tab. No clue why that happens.
Change preview fps didn't solve the problem.I noticed when the memory is taken to much,press alt+tab once again and release both of the keys immediately , the taken memory would be released as soon as u release the key. I will try to find out which function causes this ~ hacksign@XSign [12:31:57] : ~/.config/awesome/alttab ➤ awesome --version awesome v3.5.5 (Kansas City Shuffle) • Build: Apr 11 2014 09:37:47 for i686 by gcc version 4.8.2 (nobody@) • Compiled against Lua 5.2.3 (running with Lua 5.2) • D-Bus support: ✔
It turns out that, comment line 212 cr:paint() invoke resolve the memory leak problem.It seems there is something wrong when cairo draw preview on to screen.Maybe u can add a new mode to display window list, such as ... just an window list vertically like awesome main menu ?
Just a quick&dirty hack,simply display window list,hope you can add this display mode to this plugin~ https://github.com/Hacksign/configs/tree/master/.config/awesome/alttab
Thanks! I'll see what I can do to incorporate this. Could you post the versions of your software? Particularly the version of Cairo, oocairo, and Lua. I will inform the mailing-list and see what they have to say :-)
Contain some Chinese, just ignore it ;) I dont know how to get oocairo's version, command please ?
hacksign@XSign [17:45:46] : ~
➤ yaourt -Qi cairo awesome lua
名称 : cairo
版本 : 1.14.0-2
名称 : awesome 版本 : 3.5.5-1
名称 : lua 版本 : 5.2.3-1 hacksign@XSign [17:50:16] : ~ ➤ uname -an Linux XSign 3.17.1-1-ARCH #1 SMP PREEMPT Wed Oct 15 15:36:07 CEST 2014 i686 GNU/Linux
Hm you're on Arch, and I'm not familiar with pacman. On Debian I'd do $ dpkg -l | grep oocairo There must be a similar command for pacman that lists all installed packages.
There is no package called oocairo on my system ... ➤ pacman -Q|grep -i cairo cairo 1.14.0-2 python2-cairo 1.10.0-2
I received some suggestions on the mailing-list:
Change the following code (line 209): cr:translate(tx, ty) cr:scale(sx, sy) cr:set_source_surface(gears.surface(c.content), 0, 0) cr:paint()
to: local tmp = gears.surface(c.content) cr:translate(tx, ty) cr:scale(sx, sy) cr:set_source_surface(foo, 0, 0) cr:paint() tmp:finish()
And also, could you post your lua-lgi version? Mine is 0.8.0
I'll check your modify later,thanks ;) ➤ yaourt -Q|grep -i lgi extra/lua-lgi 0.8.0-1
cr:set_source_surface(foo, 0, 0) should be cr:set_source_surface(tmp, 0, 0)~ and this solved memory leak problem ... hmm ... but I prefer this mode of displying window list to the prview mode ... lol
Had the same memory leak problem... At least this solved it (as suggested): local tmp = gears.surface(c.content) cr:translate(tx, ty) cr:scale(sx, sy) cr:set_source_surface(tmp, 0, 0) cr:paint() tmp:finish()
Maybe this should be changed in master...
Thanks for the widget :+1:
Works for me too! Just a note that after applying the fix, I have several of these lines in my awesome wm log file:
/home/david/.config/awesome/alttab/init.lua:388: W: timer not started
/home/david/.config/awesome/alttab/init.lua:389: W: timer not started
Thanks for the great work you've done here.
I added the above fix in a pull request. Let's hope that this project is still active and it gets pulled fast.
When I switch applications fast, and repeat many times, my battery widget's timer function noticed me "there is not enought memory", maybe an memory leak ?