Version: 4.4.2 (using KDE 4.4.2) Compiler: unknown OS: Linux Installed from: Mandriva RPMs There are huge memory leak in Xorg server when KDE running for a long time, then Xorg memory consumption grows up to 2,5G. This bug looks like http://bugs.kde.org/show_bug.cgi?id=162273, so I just copied bug short description. cy6ergn0m@cgmachine .wine/drive_c/quake $ uname -a Linux cgmachine 2.6.31.12-desktop-3mnb #1 SMP Thu Mar 25 12:47:42 EDT 2010 x86_64 Intel(R) Core(TM)2 Duo CPU T5850 @ 2.16GHz GNU/Linux cy6ergn0m@cgmachine .wine/drive_c/quake $ kde4-config --version Qt: 4.6.1 KDE: 4.4.2 (KDE 4.4.2) kde4-config: 1.0 cy6ergn0m@cgmachine .wine/drive_c/quake $ cy6ergn0m@cgmachine .wine/drive_c/quake $ glxinfo | grep -i version server glx version string: 1.4 client glx version string: 1.4 GLX version: 1.3 OpenGL version string: 3.0.0 NVIDIA 185.18.36 OpenGL shading language version string: 1.30 NVIDIA via Cg compiler
Why do you think that kwin is leaking? Have you any values for that? E.g. increasing number of used pixmaps/memory.
I haven't reasons to think that other application can produce leaks in X server. Also, I use the same applications as I used in the past, but leak grown after update to KDE 4.4. So, I guess the cause inside KDE render engine. It may be kwin core or inside some effects thats are enabled. I do not know how can I debug these components or how to monitor metrics thats are relevant to issue.
(In reply to comment #2) > I haven't reasons to think that other application can produce leaks in X > server. Here's one: "they can" :-) Now, most important: is this a leak in RAM (what you see in "top") or in VRAM (what you see in "xrestop") if it's in VRAM and you think related to some effects, just turn off all, check whether there's still a leak. if not, reactivate them one by one until you've the culprit. (the alternative would be to use valgrind) this could also be in the decoration plugin, so please try another one as well. if it is in RAM, this is actually an Xorg / nvidia problem (maybe raised by some KDE/Qt component, though) - iirc there's been a problem with Xorg and QCursor in this regard. in doubt, attach the output of both.
Thank you for xrestop - I did not know about it. I'll monitor my system with it. System was restarted yesterday but issue requires a few days to be reproducible. But currently I can see that plasma-desktop and kwin holds more resources than other applications. On the third place I can see konqueror's window. Other applications holds in 10 times less resources.
plasma for the wallpaper and kwin as it (while compositing) has to store a pixmap for every mapped (visible) window - that's common, expectable and no leak :-) so did you notice the leak on "top" before?
Problem was related with RAM, not VRAM. X server memory consumptions was too much and system was very often swaps memory to disk because X server holds 3Gb+ RAM of 4Gb available.
"probably" as the server can map pixmaps to RAM (and they're swapped from there) to ensure the RAM leak, you need low consumption by xresources (xrestop) and high consumption in general (top) Given that you mentioned that it takes days to raise this, it's unlikely kwin as it deals with rather large pixmaps (so things should develop much faster) one possible issue might be un/mapping, though: un/minimize a (some) windows constantly and see whether you get accelerated leaking (in xrestop) if it's ram, it's a server probelm. you should upgrade at elast the nvidia driver and (if it doesn't help...), entire Xorg.
Please add some data which could verify that there is leakage and some information on where it leaks. By just stating that there is a leak we cannot even start to investigate. Sorry.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!