Version: (using Devel) Installed from: Compiled sources Compiler: gcc 4.3.0 OS: Linux Plasma (kde built from trunk on may the 14th 08) seems to leak x resources. After some hours of use xrestop shows the following: res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier 1800000 15 1 1 721 711 225872K 18K 225890K 5838 PID 5838 is the pid of the plasma process. The ~225 MB are still growing (the last time it uses over 600 MB) that makes x use a lot of memory: 369 MB for X at the moment. I am running x on a nvidia geforce 8600m-gt with closed source nvida drivers, version: 169.12.
Same here on nvidia, with or without desktop effects enabled. While keeping xrestop running, every windows focus switch seems to cost about 4-6 KB. I have focus-follows-mouse enabled, so I literally just need to move the mouse from one window to another to see plasma eat memory. Not reproducible on ATI.
I can reproduce this with composite enabled, with the open source ati drivers from git. Plasma keeps leaking pixmaps: after 2 hours uptime X eats 820 MB ram
Same here, on nvidia with the latest drivers and composite enabled. Plasma has been running for few hours and xrestop shows 150MB pixmap usage for it.
I tried to find out what is causing this. I found one leak which I could reproduce on nvidia with composite, on vesa without on Intel Graphics wihtout. But there must be more (while i think that some of them are only there with composite enabled). The one I found ist in the Taskbar Applet. On every redraw of an item in the taskbar it adds von pixmap to X with about 1-4 kilobyte each. (to reproduce just bring up two smaller windows on top of the screen and switch focus bitween them over and over again while looking at the output of xrestop) If you disable the drawing of the icons of the taskbar items (in the source (windwstasbaritem.cpp the m_icon.paint() call)) this leak is "fixed". The problem is m_icon is a QIcon so the bug is in QT?!? Ok i do no know enough about that, so maybe else can use this information. It stops
I see this in trunk, XOrg 7.3, Nvidia 173.08. The memory usage goes up constantly, especially if I maximize a window. xrestop says plasma is using the most pixmap memory. I got 1000K increase in 7 minutes. I killed plasma when it was using almost 90000K. Unfortunately according to top the memory usage of XOrg is unchanged, VIRT 727m, RES 118m
András Manţia: Here the usage drops after killing plasma. Don't look at the VIRT value.
Sorry, I misstyped. RES is 585m, I think that is more important. I made further testings: - disabling of Desktop Effects helps. I cannot reproduce the increase with that. - when it is enabled I get a quick increase in Pxm mem if I hide/show a fullsize window, e.g konversation. It doesn't happen with every window though. Actually it doesn't happen with KDE4 applications, only if I show/hide KDE3 apps! - turning of all effects (but letting the Desktop Effects enabled) makes no change - switching from opengl to xrender or changing the opengl settings does not help - removing all plasma applets except the panel makes no change - removing the wallpaper does not help I have "UseCompositeWrapper" "true" in xorg.conf, as otherwise some KDE3 apps bring down X.
Here is a valgrind leak check for plasma. I started, minimized/maximized konversation to see the increase in xrestop and killed plasma with kquitapp. I see that 2,371,670 bytes are still reachable, the most of them comes from a QFontMetricsF usage. Can be this the problem? I'm unsure if valgrind really catches X resource usage... (BTW Folderview also has a problem according to the log).
Created attachment 25097 [details] Valgrind log
Further testing: happens with KDE4 apps as well. The criteria is the following: if the app is minimized to the systray, the leak happens. If it is minimized normally to the taskbar, everything looks fine.
I have the same problem here. I tried to disable desktop effects and switch from OpenGL to XRender and the problem continues on every try. My Video Card: nVidia GeForce GO 6150 nVidia driver: 173.14.05 Linux Distribution: Gentoo 2007.2 KDE version: SVN
Did some testing...removing the task manager stops the leak for me. I'll use without task manager for a few hours and see more.
SVN commit 818642 by aseigo: deleting things. what a bloody good idea. *rolls eyes* BUG:162138 M +12 -5 tasks.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=818642
I think i'm still having this bug. I've just updated my KDE SVN and everytime i change the focus of a window, the memory usage increases. It happens with and without desktop effects. My Video Card: nVidia GeForce GO 6150 My Video Drivers: nVidia drivers 173.14.09
Pxm mem increases by ~20kB every time I change window focus, using KDE 4.1.2 with the radeon driver. It also increases by ~10 kB every time I switch tabs in konsole.
Guys, could you reopen this bug. It's still happens here with xorg-server-1.5.2, and sis drivers. After 1.5 week of uptime it eat all memory here (256Mb). Plasma still leaks! And composite is not enabled here at all. kde-4.1.2 installed here...
Same here (X pixmap memory leaks), but I haven't verified details..
Bug reopened, see xrestop from today :( 1a00000 31 1 0 1259 1092 766786K 26K 766813K 26222 Qt-subapplication after restarting plasma: 1a00000 35 1 0 299 377 21594K 9K 21604K 29689 Qt-subapplication Using trunk, revision 897321, nvidia 180.11
I'm seeing this problem lately too, now I'm on KDE 4.2 Beta 2 from OpenSuse's repos, with the latest nvidia beta drivers (180.16). It seems that when you minimize something into systray and bring it back, Plasma's pixmap usage seems to climb up many megabytes. I had Xorg (1.5.2) using like 1.2GB of memory, out of 6GB.
"It seems that when you minimize something into systray and bring it back" define "something" and "minimize into systray". on a sidenote: re-opening this bug was not the appropriate action to take, nor is adding random comments about potentially unrelated items to it. It's like having one bug for all crashes or something equally silly ;) I already closed one memleak report for that reason: we'd fixed various issues reported in it and people kept dog piling in new issues related to memleaks. Please, please open a new report for new issues.
Aaron, the behavior is very similar to what I described in comments 7-10 so I found it appropiate to repoen the report. plasma uses 57062K pixmap memory, ater minimizing konversation to the systray it uses (click on it is icon), it uses 62604K. Do it several times a day and you will end up with 1GB used by plasma. This is reproducible. Sometimes minimizing simply by clicking on the taskbar entry also increases the usage, but here I couldn't find a pattern.
This leak sounds to be what I experience here with FC10 from Fedora repositories up-to-date per today with kde-workspace-4.1.3-7.fc10.i386. Beginning with F10-preview thru today the visible effect is for plasma to use increasing amounts of memory and CPU resource but at a growth rate much slower than seen in the post and first dozen comments. I have just found 297MB & 25%CPU [2GB & 2AMD installed] allocated to plasma after 24hrs of "idle" operation following login (3 applications running: Firefox, thunderbird, ksysguard). Plasma originally consumed 9MB & trivial CPU immediately after login. In my case, I logged in and have not touched the system for a day, thus the growth does not require my interaction, and the windows were minimized. Further more, the heavy CPU consumption is cyclical at perhaps 6(?) seconds followed by a couple seconds of idle? My work-around is to logout then login to regain the resources. In my personal experience plasma seems to always produce good results -- I can't identify any specific operational fault. If this comment points in a direction of any value, I'll be happy to provide any further detail useful to isolate the cause.
i closed a bug report just last week about "memory leaks" because in that one report were reports for probably half a dozen *different* issues, and for most (including likely the original reporter) it was the nvidia binary driver. i really don't want to see a repeat of that. so ... please do not simply tack on "oh, i've got a memory leak too!" report or add on reports with rather different symptoms (e.g. CPU usage). open *new* reports and let the plasma team deduce with you, one at a time, whether they are indeed the same issue or not. i'd much rather have to go around marking things as DUPLICATEs rather than having monster reports with N different issues in them that are impossible untangle. for now, let's try and bring this one to a conclusion in any case: Andras ad Verduin, which x.org driver are you using?
When I reopened the report, I was using nvidia 180.11 (on openSUSE 11.0, self compiled KDE SVN), now I'm using openSUSE 11.1 with 177.82. The symptoms are the same. Note, that after I installed 11.1 I run the shipped KDE 4.1.3 binaries and there was no noticeable leak, but as soon as I switched to svn, it become visible again (the nvidia driver remained the same).
Hi, I can also confirm it. When I was using KDE 4.1.2, I couldn't see any noticeable effect of this bug. My system is: XORG 1.3.0 nVidia drivers 177.82 When I have installed KDE 4.2b2, I started to see this bug again. But in a much "lighter" version than the one in KDE 4.0.*. Now, when the system stays on for one day, the memory usage of plasma is about 70~120 MB, in KDE 4.0.* time it would be 250~300 MB. So I have two considerations: 1) The "new" bug has the same appearance of the old one; 2) As a read the posts, I saw that in some cases plasma is using much more memory and the bug is much more noticeable than here. This people are using nVidia cards as me, so I think that the problem should be at XORG. My version is 1.3.0 and the bug here is almost not noticeable. So, what are your XORG version?
(In reply to comment #23) ... please do not simply tack > on "oh, i've got a memory leak too!" report or add on reports with rather > different symptoms You are most certainly correct that I can not determine there is a "pixmap" memory leak in my post, but the 162138 thread does seem much like my experience so I did choose to not open a new bug -- sorry / I won't go further here. Andras ad > Verduin, which x.org driver are you using? Does this excerpt from X...log answer your question? ================================================================== (II) Loading /usr/lib/xorg/modules/drivers//s3virge_drv.so (II) Module s3virge: vendor="X.Org Foundation" compiled for 1.4.99.901, module version = 1.10.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 4.0 (II) S3VIRGE: driver (version 1.10.0) for S3 ViRGE chipsets: virge, 86C325, virge vx, 86C988, virge dx, virge gx, 86C375, 86C385, virge gx2, 86C357, virge mx, 86C260, virge mx+, 86C280, trio 3d, 86C365, trio 3d/2x, 86C362, 86C368 ================================================================== > cheers George
first, i don't think this leak has much, if anything, to do with older ones. i say this because we have fixed several other issues between now and then. as you are both using the binary nvidia driver, could you put up with the pain of trying the open source nv driver for a day and see if the leak persists? the last person who tried that noted that the leak was not present with the open source driver.
Not what you want to hear, I'm sure, but I'm using the open source radeon driver... so this isn't a nvidia-specific issue.
@Luke-Jr: that driver may have a similar bug too. if this turns out to widely be a "when a use driver Foo i get a leak, when i use driver Bar i don't" then we can start to look to drivers as the issue. lots of drivers had the same or similar argb related bugs at the beginning of this year which have since been fixed.
The nv driver doesn't show such a big leak (according to xrestop there is some raise in the memory usage, but not that much). The binary nvidia driver with the desktop effects disabled (the option, not the effects themselves) also doesn't show the leak. Switching the rendering mode or disabling all th effects, but keeping the effects option enabled doesn't solve the problem. Aaron, remember that comment #26 shows an S3 driver, meaning there is already 3 drivers showing the leak. And that the nv and nvidia without the effects doesn't use any 3D AFAIK.
@Andras: the cpu usage and memory increase could be due to all sorts of things in comment #26. e.g. they could be using the twitter plasmoid, something that had some horrific leaks and still has an unconfirmed cpu usage issue. this is why we have to be very careful when saying "oh look, there is a memory leak bug, it's the same as this one!" as for the nvidia driver not showing the leak when effects are turned off doesn't help much, since that just says that isn't argb (only) related. so... it could be due either to the driver or due to something that relies on compositing being active. can you update kdebase/workspace/libs/libtaskmanager? i just removed some old and unused code in there that was only active when compositing was available. it's a bit of a long shot, but we're running out of places to look in plasma.
This is not specific nvidia problem. I can easily reproduce it with SIS driver: Silicon Integrated Systems [SiS] 65x/M650/740 PCI/AGP VGA Display Adapter Also I don't have compositing enabled/active. I even have opengl disabled whenever possible since my video card does not support dri.
Good news. After updating today (following Aaron's advice) it looks like the leak is mostly gone. I say mostly, because there is no big increase anymore in the X resource usage as before. It still increases slightly, I will try to test if this increase is different or not if I use the binary or the nv driver.
ironically, the code i removed was a hack from kde3 in libtaskmanager that we don't use anymore because kwin has proper compositing hacks. unfortunately, it was still active when compositing was. *sigh* small increases after start up are to be expected depending on what plasma is doing as it will be adding to its RAM-backed pixmap store as it paint things. it should eventually peak out, however. on my machine it has 20MB for the RAM based cache, and then there is the overhead of svg objects around that as well.