Bug 183191

I checked with valgrind, and i can't see a memory leak. what graphics driver are you using? "older" nvidia driver seemed to have leacks with kde4

I tried w/ nvidia drivers 177.82 and now w/ 180.27. Also tried w/ xorg server 7.3 and now 7.4

Note: the digital clock is in panel per default Markus. So this should affect all users. Are you saying that show date and seconds trigger it for you? Can you be more specific and monitor the behaviour 
1) as default
2) with date and year
3) with date and year and seconds

You said
"* wait some time and see raising up memory usage every second in htop "
can you define "some time"?

htop gives me 2.7 and it stays here for plasma, I don't see any increase. I use KDE from trunk, self-compiled. I have been monitoring for 1 hour 1/2

(In reply to comment #3)
> Are you saying that show date and seconds trigger it for you?

Yes, as soon as I activate the seconds in that plasmoid every two seconds the RAM usage goes slightly up. If I disable the seconds that behaviour stops

> Can you be more specific and monitor the behaviour 
> 1) as default
> 2) with date and year

Non issue so far

> 3) with date and year and seconds

as said above, this triggers it

> You said
> "* wait some time and see raising up memory usage every second in htop "
> can you define "some time"?

some minutes (<5 minutes)

> htop gives me 2.7 and it stays here for plasma, I don't see any increase. 

plasma is ATM at ~64 MB RAM usage (disabled seconds for now)

> I use
> KDE from trunk, self-compiled. I have been monitoring for 1 hour 1/2
 
Gentoo ebuilds here (4.2.0, stable packages)

Hi,

I can reproduce this problem.
Only enabling seconds in the digital clock plasmoid is enough.
Then wait a few minutes (I can confirm less than 5mins), then plasma start to grow RSS around 8k by seconds.
When seconds are not enabled, the problem does not appear.

Same configuration as Markus : Gentoo (x86) running kde 4.2.0 via portage ebuilds.

I can confirm it with Kubuntu 8.10 too and with the analog clock (with an Intel 935M graphics card).

if i open the configuration window  in htop i see that the memory is increase of 1-2Mo but if i close  the configuration window, the size isn't decreased ( with kde 4.2.0)

see also:
https://bugs.kde.org/show_bug.cgi?id=182900
https://bugs.kde.org/show_bug.cgi?id=184394

Running the digital clock on plasmoidviewer with valgrind doesn't show anything that could trigger this memory leak...

Was it set to show seconds? Maybe the bug is triggered only when the clock is on panel? All I know is that when i disabled second showing the leak disappeared.

Hi.
I have also noticed this behaviour. Enabling the display of the seconds in the digital clock widget leads to a leak by the plasma pid. Using xrestop, I have 40K more memory every one or two seconds that is used.

I'm using KDE 4.2.2, Debian Sid. Have bugreported it too debian BTS (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523875).

i can duplicate this. it seems to be a leak related to the caching done by QGraphicsScene. 

watch this (Qt-only) test app in xrestop: http://bddf.ca/~aseigo/leakage.tar.gz

the problem is that when the pixmaps are inserted into the pixmap cache, even though they have the same key, the pixmaps are not being deleted. so there's another pixmap there for each and every update. obviously this is fairly expensive. we'd see it a lot more if plasma wasn't so conservative in its updating these days.

anyways .. if the two calls in qgraphicsscene.cpp to QPixmapCache::insert are prefaced with a call to QPixmapCache::remove the problem not longer presents itself.

(and the reason valgrind won't show this is that it isn't unreferenced memory in the application)

wOOt. Pretty bad. I know the first thing i will do tomorrow :D.

hm.. i suppose i should mark this as upstream.

It is fixed in Qt but in any case the amount of memory that QPixmapCache can take is 10Mb, then after it delete old entries to add new ones. But i fixed the fact that we didn't replace the pixmap if you re-add a new one with the same key in the cache. That wasn't a leak because at the end of the app everything is released but that was a stupid usage of the memory.

Two questions: 

Is the mentioned patch applied to qt-copy trunk yet ?

Could this be related to this pixmap leaking bug ?

http://www.nvnews.net/vbulletin/showthread.php?t=131864

I actually run the patch that i have made to QPixmapCache (this one is scheduled for 4.5.2) and plasma is still leaking pixmap memory... Something else happen somewhere else.

plasma as a whole or `plasmoidviewer digital-clock`?

Actually i didn't tried plasmoidviewer but i will do it. plasma-desktop was leaking.

@Alexis: 4.2 branch or 4.3 trunk ?

Trunk

As discussed with aseigo I removed the digital clock applet from the panel and instead put an analog clock applet on the workspace. The result of this experiment was that plasma was stable the whole day. So for me the memeory leak has to be somewhere in the digital clock applet.

re-opening to track the next set of ensuing issues ...

*** Bug 183646 has been marked as a duplicate of this bug. ***

*** Bug 192190 has been marked as a duplicate of this bug. ***

Here we go, i finally found the issue in the plasma code. After some days my plasma show only 129 pixmaps in xrestop instead of 10000. I'll backport the patch in 4.2 branch as well and i will commit in qt-copy the one in Qt that will be in 4.5.2.

This one gets you a virtual cookie, thanks very much Alexis for fixing. I'm curious about the patch being in 4.2 branch. Again, thank you!