Slackware64-15.0: Memory leak in kwin_x11?
Hi, I was wondering if anyone else suspects a memory leak in kwin_x11... I've tracked kwin_x11 memory use for some time using:
Code:
ps -u -q `pidof kwin_x11` Code:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND Code:
elogind-daemon[1929]: Failed to suspend system. System resumed again: No space left on device So, rather than just suspending and not hibernating, I thought it might be interesting to track memory use. I noticed that, after a couple of days, kwin_x11 comes up as the process that uses the most memory. So, does anyone else notice this? And does anyone perhaps know of a patch? A very cursory google search didn't yield anything conclusive... |
Can you post the output of this?
Code:
kwin_x11 --version |
Code:
$ kwin_x11 --version |
If you open and close an app window a few times does that makes the memory usage go up? That's usually a good way to tell with leaky window managers.
P.S. Don't you just love progress! Code:
$ ps -C fvwm -o vsz,rss,sz,cmd |
It appears that the RSS value keeps rising... I dragged one window around, minimised / maximised it, switched back and forth between some virtual desktops, etc., (so, no new processes, just some window operations), and RSS kept slowly growing. The other two values stayed the same. Laptop is up for two days now, and kwin_x11 has the highest memory use of all processes.
I polled every second, I snipped out a couple of lines, but you get the picture. I no case does kwin_X11 RSS get lower. Code:
~$ while true; do ps -C kwin_x11 -o vsz,rss,sz,time,cmd; sleep 1 ; done Quote:
Anyway, would be nice to know whether others see the same (or maybe I'm wrong and steadily rising RSS does not equal memory leak). If all else fails, I may try to compile KwinFT and see how that works. |
The problem is that RSS of a task will increase as pages of any shared library it uses gets loaded into ram by *any* process (they get counted in each processes RSS whether that process is actively using those pages or not), so for something using a lot of shared libraries RSS increasing over time would be expected as more and more of the shared library will be in ram as new functions are called for the first time. Eventually those pages might get paged out due to page-stealing and RSS could potentially go down, but again that says little about the process itself.
If the process were leaking I'd expect sz and vsz to be increasing (with each new malloc or stack expansion). P.S. If you want to get a proper look: /proc/$pid/maps or the front-end 'pmap' command that makes it a little more human friendly will give you more detail than you care to know. |
Nevermind, I thought I saw VSZ increase, but it didn't really...
|
Actually, I _do_ see kwin_x11 VSZ increase steadily over time. Not when I'm playing around with windows, but still. I've logged mem use over the past eight days. I've suspended a couple of times during that period, but never logged out. At one point, I did close and open chromium, firefox and some writer documents, but the number of running applications is mostly stable.
I'm still wondering whether anyone else has similar results. I can't imagine that I'm the only one accustomed to being logged in for weeks on end ;) Below the log: Code:
%MEM VSZ RSS SZ TIME |
Quote:
That's not to say there aren't leaks in kwin, probably there are such conditions. I've concretely found such situations with kmix too, but I was never able to fully track down and verify any cases of kwin issues like this. With the first case, I struggled with this situation for quite awhile, and if my memory doesn't betray me, in some of those cases the main suspect at first was kwin, but when I tracked down and investigated the issue, it was in the end not. I've never had these issues (except the kmix one) since I imprisoned Firefox in a pool of water, which leads me to believe that all those problems were in the end caused by Firefox. But who knows, these issues are tricky to pin down and verify. Kwin can in some case look like the culprit, but merely be reacting to a situation indirectly which isn't a problem with kwin, but rather some other issue. But then again, most of these issues I've also not had on Slackware 15, but rather when I was using Mageia. -I guess what I'm trying to add here is that I've had similar situations. -It's difficult to track these issues down properly -Some issues that might at first seem like a kwin issue, is rather some other issue, and kwin is reacting to it as it should -Some other issues might indirectly cause kwin to react in ways that it shouldn't -It's possible that there are some conditions like this in kwin too -I've seen similar issues with other kde software (kmix), although I was not able to track down the cause (with my setup it could very well have been caused by another issue) -These things (kwin) probably also behave differently depending on if Xorg/Wayland is used |
glibc malloc is very lazy for deallocating pools of memory. Memory can be freed with the free function after malloc or realloc but it isn't really freed because the system think it can be reused later. So the pool from which the alloc came tends to remain as long as the process is here.
For process than never ends like kwin, the virtual memory tends to never decrease. Some alternate allocators like jemalloc tries better to relax free unused memory. The kernel has added some way to help for that (around madvise kernel calls). |
All times are GMT -5. The time now is 12:10 AM. |