Version: 20080630 (using Devel) Installed from: Compiled sources Just after KDE start I see that plasma about 15mb of memory on "Sistem activity". After several hours of use, the same desktop on plasma uses more than 60mb. That makes me think that plasma is leaking memory. What can I do to help?
post the output of xrestop, try removing applets/plasmoids to see which (if any) triggers the problem, watch to see if it continues to grow in size over time.
just downloaded xrestop and can't see plasma on it...
got it fomr pid! i'll send the results later
** At 11:20 (13mb on SA): 0 - ( PID: 8614 ): res_base : ox1c00000 res_mask : ox1fffff windows : 12 GCs : 5 fonts : 0 pixmaps : 160 pictures : 186 glyphsets : 26 colormaps : 0 passive grabs : 0 cursors : 1 unknowns : 8 pixmap bytes : 14923134 other bytes : ~5712 total bytes : ~14928846 At 21:11 (35.7mb on SA): 0 - ( PID: 8614 ): res_base : ox1c00000 res_mask : ox1fffff windows : 16 GCs : 1 fonts : 1 pixmaps : 481 pictures : 509 glyphsets : 29 colormaps : 0 passive grabs : 0 cursors : 4 unknowns : 14 pixmap bytes : 15518906 other bytes : ~14776 total bytes : ~15533682
I did remove all the widgets on the desktop and the panel, and the memory used on system activity was almost the same
could it be a duplicate of 162138 ? does this happen again?
yes, plasma is still leaking memory
problem also on a dell m1330, with a intel 3100 video card. (so not a nvidia leak problem)
I can confirm the same problem. I have kde packages from Fedora rawhide (kdebase-workspace-4.1.0-3.fc9.x86_64) and Intel 945 video. After two days of work plasma eats 25% of my 1G ram, after restart - 2.3%.
I can confirm that. I use the PPA ubuntu repos for KDE 4.1. After 15 days of uptime I noticed that plasma used over 300 mb. After asking in the #kde channel on freenode I was told to: (1) kill plasma (2) rename my two plasma configs (3) star plasma again Well, I did so, it started with something like 35mb and a day later it has risen to 74mb. I was then told to just switch windows for a minute and see if there is a difference in usage. So I did and I noticed a 800kb increase in memory usage. So I did restart plasma again and made a screen shot ( http://www.sjau.ch/kbug_165423/plasma_leak1.png ) and then for 2-3 minutes I just toggled windows between konqueror, kdepim, firefox, screen terminal konversation and ksnapshot. After those 2-3 minutes plasma used about 1.4 mb more memory ( http://www.sjau.ch/kbug_165423/plasma_leak2.png ).
I can't reproduce this in 4.1, even doing exactly what hyper_ch is doing. Is there any chance of replicating this with valgrind? Just run kquitapp plasma; sleep 1; valgrind --leak-check=full --log-file=plasma-leaks.log plasma --nofork and re-create the memory increase, then post plasma-leaks.log here. Note the plasma will be _VERY_ slow when running under valgrind.
Created attachment 26964 [details] Plasma Leaks Log I did now run that valgrind thing but didn't have time to switch windows a lot.
That log doesn't show any leaks as such, but that's not to say that something isn't collecting pixmaps, say. If someone who is seeing this behaviour is willing to run plasma under valgrind for longer (long enough to get an increase in memory usage of at least a few megabytes, say), something might show up.
maybe this bug has something to do with http://bugs.freedesktop.org/show_bug.cgi?id=14639 the bug happens on intel gm965 and a nvidia 7000m (proprietary driver), as I had the opportunity to test on both.
Created attachment 27049 [details] Leaks summary from valgrind This is from running plasma for some time. This is done with leak-check=full and --show-reachable=yes. So some of the reported leaks are just memory that is used basically until the application quits, and so plasma (or whatever other bit of the stack that creates it) doesn't bother deleting it.
Plasma today (4.1.1) reached 83 MB of memory I did a quick kquitapp plasma and then restarted it, and now it opens with 18 MB this is a difference of more than 60MBs Does this indicate there is a possible memory leak? [Note: I am on the 177.70 nvidia driver]
Yes, but I'm having real difficulty finding what keeps using more and more memory.
Created attachment 27435 [details] Plasma memory consumption in System activity 160 Megabytes!! Please if anything we users can help do to discover the cause of this thing, then please post us detailed instructions on how to investigate.
Seems leak does not occur if desktop effects are disabled..? Using nvidia 177.70 driver, it definitely occurred with desktop effects enabled as I could barely keep 2 days uptime.... at 3 days uptime now though, its still only using 20 megabytes for my 2560x1600 display.
@Jason: no .. I have desktop effects disabled.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME P COMMAND 2991 tuju 20 0 514m 51m 18m S 44.5 1.3 5:48 3 /usr/bin/plasma 2744 root 20 0 1100m 431m 16m R 30.6 10.9 7:38 1 /usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-XUyumz res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier 1a00000 15 3 0 346 432 22982K 10K 22993K 2991 3200000 332 52 1 702 211 18643K 14K 18658K 3111 Akregator 1600000 297 3 1 389 1435 13248K 41K 13290K 2985 kwin 4e00000 530 126 1 986 496 5960K 28K 5988K 4343 Amarok 4000000 2 1 1 152 170 4878K 5K 4883K 3141 Okular 2800000 5 1 1 334 383 4610K 10K 4620K 3035 tuju : xrestop 0000000 2 0 2 0 97 4500K 4K 4504K ? <unknown> 4c00000 30 1 1 285 336 4360K 9K 4369K 3162 YouTube - How To Marshall Jets Brit Style - Konqueror Could someone make a plasmoid-top with cpu-meters so that these problematic plasmoids would be easier to find? I tried to drop some plasmoids but could not figure out which one causes it. Also, sometimes my load drops below one for a while. We loose 100% of car engine to generate electricity for a dashboard with meters, lamps and levers. That can't be right.
And why assume that the leak would come out of a plasmoid? My list of plasmoids seem very innocent that it is non-conceivable that these simple plasmoids have a leak, but I will list them anyway for reference: On the desktop: - 4 icons - Clock On the panel (only one panel): - Application launcher - Show desktop - Task manager - Current devices - Text clock + system tray Desktop effects disabled. I am posting this and plasma now is eating up 500 MB of memory according to system activity!
i'm beggining to think this is a qt's graphicsview memory leak, maybe something related to its cache...
I have plasma leaking pixmap memory here. Right now plasma is at 50 MB, xrestop indicates that pxm mem is increased by 10 kB every time I switch tabs in konsole.
Forgot to mention: this is KDE 4.1.2 from the opensuse repositories.
Can confirm on Mandriva Linux Cooker: Plasma starts from about 1.5% of memory and climbs to 8.7% of memory (out of 2.5GB RAM + 1 GB of swap). I'll try to diagnose with xrestop later on.
In kde 4.1.69 (KDE 4.2 >= 20081009)) the problem is gone (I've suffered it). plasma started with 22Mb and now is using only 17Mb after 1 day.
Well, it is almost gone. it increases the memory when the tooltips of the icons in the panel are shown (around 4k with each new tooltip).
Each _new_ (never-shown-before) tooltip, or each time a tooltip is shown? And does it drop again when the application the tooltip is for is closed?
It happens with each _new_ (never-shown-before) tooltip. And is not released after the application is closed.
Can also reproduce now on kdebase4-workspace-4.1.71-5mdv2009.1.src.rpm 's plasma. plasma consumes 8.5% of my 3.5 GB of RAM!
@Jaime: the memory usage on new tooltips should be gone at this point.
I've been wondering why I did not suffer the memory leak in one machine A (source compiled) but suffer it in the other B(opensuse). The difference seems to be KDE3 applications. Without them, a constant 256 Mb virtual memory in machine A, with KDE3 konqueror running, that memory grows 1Mb every hour (more or less). I have not tested with gnome applications.
(In reply to comment #33) > I've been wondering why I did not suffer the memory leak in one machine A > (source compiled) but suffer it in the other B(opensuse). > The difference seems to be KDE3 applications. > Without them, a constant 256 Mb virtual memory in machine A, with KDE3 > konqueror running, that memory grows 1Mb every hour (more or less). > I have not tested with gnome applications. > very interesting jaime. maybe a bug related to the systray applet?
same here PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P CODE DATA COMMAND 21362 lianqiw 20 0 538m 153m 30m S 0 2.6 25:38.25 1 4 172m plasma res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier 1c00000 24 1 0 3620 3789 39691K 89K 39780K 21362
I doubt it's the systray if konqueror is affecting it.
Using KUbuntu 8.10. Plasma using 500MB of memory. (It's been running for days, don't know at how much it started). I am not using any cool effects or many widgets.
Ok, here's what I'd appreciate from each reporter: * List of widgets you are running. If the list in the panel is "menu, device notifier, pager, taskbar, (battery?), systemtray, clock" just say "default set" =) * Distribution of Linux or operating system you are using, along with version number * Video card and graphics driver version * Whether you have one screen or multiple screens * Whether you run KDE3 applications or not thank you.
Hi! While trying to start KDE 4 to test for this I ran into this bug on Mandriva Cooker: https://qa.mandriva.com/show_bug.cgi?id=45915 and as a result cannot effectively run KDE 4 as a standalone desktop (not even as a new user). So a lot of this is from memory. (In reply to comment #38) > Ok, here's what I'd appreciate from each reporter: > > * List of widgets you are running. If the list in the panel is "menu, device > notifier, pager, taskbar, (battery?), systemtray, clock" just say "default set" > =) > I'm not using any special widgets. I think I added a clock, a pager, and some other stuff that were absent, but that's it. > * Distribution of Linux or operating system you are using, along with version > number Mandriva Linux Cooker (Cooker being the Mandriva bleeding edge). I update it, regularly. > > * Video card and graphics driver version > 01:00.0 VGA compatible controller: ATI Technologies Inc RV630 PRO AGP [Radeon HD 2600 PRO AGP] x11-driver-video-radeonhd-1.2.2-0.20080927.2mdv2009.0 > * Whether you have one screen or multiple screens > I only have one physical screen, but I have 8 virtual desktops, and also have several activities. > * Whether you run KDE3 applications or not > I am running many KDE 3 applications (kmail, Kopete, Amarok, etc.). And some GNOME apps. Regards, -- Shlomi Fish > thank you. >
With opensuse 11.0, nighly builds, versión KDE 4.1.73 (KDE 4.1.72 (KDE 4.2 >= 20081112)) "release 3.3", I have another way to increase plasma memory using kickoff menu. Every time I search something new (not searched before), and move the mouse over the list, memory increases and is not released. More information: Widgets: default set + 1 folder view Distribution: opensuse 11.0, linux 2.6.25.18-0.2-pae Video Card: ATI Radeon 9550 (driver ati propietary 8.9) Screen: One screen with 4 virtual desktops KDE3: amarok, k3b By the way: the memory usage on new tooltips is gone.
Created attachment 28750 [details] plasma valgrind output I am running kubuntu 8.10 (KDE 4.1.3) on a laptop with an ATI graphic chip (01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 Series]) and I am also seeing plasma growing. I ran a alittle test for few hours that would start konqueror every 5 secs and then killing it. I am attachig the valgrind output for plasma. with my little test above xrestop is also showing that the number of "Pxms" and "misc" keep increasing and will almost never go down.
The valgrind output shows no significant memory leaks. I've fixed a few in the device notifier using the logs, but they were in the order of a few kilobytes. The largest leak is 238Kb of thread storage for OpenGL (I think - it's the last item). My guess is that the memory isn't being leaked in the normal sense, but something is holding onto objects (pixmaps?) unnecessarily. And/or pixmaps are being created on the X server and not being cleaned up. Not sure how that might happen, though.
I use trunk built on 12/14 from ubuntu neon packages with qt 4.4.3 Nvidia 180.11 and desktop effects enabled. My other plasmoids are default desktop and lancelot. For the past 2 days i have done informal investigation into the twitter applet. For me it has increased xorg use to 500 megabytes and plasma to over 100 megabytes. This leak takes days to develop so it is a slow leak at about a meg an hour. I don't know how better to test it, but if you have an idea I will do it.
Created attachment 29368 [details] plasma-leaks.log KDE 4.1.82, gentoo (kde-crazy overlay), nvidia 7600 latest beta drivers (180.16) One screen with default 4 virtual desktops. Applets: Upper panel - taskbar Bottom panel - menu - device notifier - pager - Icons: kate, Firefox, Thunderbird, krusader, konsole4, konsole3 - panel spacer - systemtray - system monitor: network - system status - luna - battery - digital clock Desktop: 1x Folder view, 2x yawp (yet another weather plasmoid) Kde3 applications: krusader, amarok, konsole3, knetstats, kWinDisk, basket Other applications: psi, skype I have also a different problem. Sometimes (I did not investigated yet the conditions), plasma starts to grow very quick. Eat all memory and start swap. This evening it happends three times. I had to kill the plasma. First time it happen several minutes after start. Plasma was killed. Then I start again and connect via cisco-vpn. Was OK for 1 hour. Then disconnect and again I had to kill plasma in several minutes. New start of plasma, the same. Then I started plasma with gdb - 20 minutes no problem :-(. Valgrind - 20 minutes no problem :-( I'll continue with investigation. But anyway, I'm attaching the valgrind log. The biggest leak found is in tooltip: ==30429== 1,351,046 (24 direct, 1,351,022 indirect) bytes in 1 blocks are definitely lost in loss record 103 of 497 ==30429== at 0x4A0803C: operator new(unsigned long) (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==30429== by 0x31059B9C86: QGridLayout::addItem(QLayoutItem*, int, int, int, int, QFlags<Qt::AlignmentFlag>) (qgridlayout.cpp:1515) ==30429== by 0x31059B9DA9: QGridLayout::addWidget(QWidget*, int, int, QFlags<Qt::AlignmentFlag>) (qgridlayout.cpp:1555) ==30429== by 0x3579B0467D: Plasma::ToolTip::ToolTip(QWidget*) (tooltip.cpp:152) ==30429== by 0x3579B1AB27: Plasma::ToolTipManagerPrivate::ToolTipManagerPrivate() (tooltipmanager.cpp:63) ==30429== by 0x3579B19A40: Plasma::ToolTipManager::ToolTipManager(QObject*) (tooltipmanager.cpp:115) ==30429== by 0x3579B19C1C: Plasma::._265::operator->() (tooltipmanager.cpp:106) ==30429== by 0x3579B19CDF: Plasma::ToolTipManager::self() (tooltipmanager.cpp:110) ==30429== by 0x3579AD1F9E: Plasma::Corona::Corona(QObject*) (corona.cpp:200) ==30429== by 0x4C426C8: DesktopCorona::DesktopCorona(QObject*) (desktopcorona.cpp:40) ==30429== by 0x4C54634: PlasmaApp::corona() (plasmaapp.cpp:424) ==30429== by 0x4C55913: PlasmaApp::setupDesktop() (plasmaapp.cpp:240) ==30429==
@Anthony Archer: I've heard rumour that 180.16 fixes the leak for those who have been experiencing it. can you try 180.16 and confirm/deny this for us? thanks... http://www.nvnews.net/vbulletin/showthread.php?p=1873716
@Marian Kyral: that's not actually a leak; the tooltip is not deleted if the application is closing as it prevents order-of-deletion crashes. the operating system cleans up that memory for the application. ~ToolTipManagerPrivate() { if (!QCoreApplication::closingDown()) { delete tipWidget; } } as for your problem, when you can investigate it further, please open a new bug along with your plasma-appletsrc and as much additional information as you can gather. @all: i committed a number of memory leak fixes to the twitter widget just now. if you were using twitter, plasma (and x.org) would slowly grow over time more and more. that has been addressed. as for this bug.. i'm going to be closing it because it's not just one bug anymore but a report containg N miscellaneous issues. some were leaks in the tasks widget, some in twitter, some in the graphics driver, some .. who knows. as such it's impossible to manage this report: it can never be really "closed", i can't keep track of which leaks have been dealt with and which haven't, etc. if you continue to experience problems with the *next* release (so either 4.2 beta 3 or RC1 or whatever it gets called) or with svn from today onwards, please open a *new* report for that *specific* leak. thanks =)