Bug 183191 - possible memory leak in digital clock plasmoid
Summary: possible memory leak in digital clock plasmoid
Status: RESOLVED FIXED
Alias: None
Product: plasma4
Classification: Plasma
Component: widget-clock (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
: 183646 192190 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-02-04 16:22 UTC by Markus Rennings
Modified: 2009-05-22 15:33 UTC (History)
16 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Rennings 2009-02-04 16:22:54 UTC
Version:            (using KDE 4.2.0)
Compiler:          gcc (GCC) 4.1.2 (Gentoo 4.1.2) 
OS:                Linux
Installed from:    Gentoo Packages

It seems to me that the digital clock plasmoid leaks memory. 

To reproduce:
* open an terminal (urxvt, konsole, xterm)
* call htop in there, and press M to switch sorting to memory usage
* now add the digital clock plasmoid to taskbar
* setup the plasmoid to show date w/ year and to show the seconds
* wait some time and see raising up memory usage every second in htop
Comment 1 Beat Wolf 2009-02-04 16:54:31 UTC
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
Comment 2 Markus Rennings 2009-02-04 17:03:15 UTC
I tried w/ nvidia drivers 177.82 and now w/ 180.27. Also tried w/ xorg server 7.3 and now 7.4
Comment 3 Anne-Marie Mahfouf 2009-02-04 18:32:03 UTC
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
Comment 4 Markus Rennings 2009-02-04 20:08:28 UTC
(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)
Comment 5 Guillaume Castagnino 2009-02-06 10:33:35 UTC
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.
Comment 6 Davide Castellone 2009-02-09 16:16:28 UTC
I can confirm it with Kubuntu 8.10 too and with the analog clock (with an Intel 935M graphics card).
Comment 7 Nicolas L. 2009-02-25 01:52:28 UTC
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)
Comment 9 Artur Souza (MoRpHeUz) 2009-02-28 00:39:20 UTC
Running the digital clock on plasmoidviewer with valgrind doesn't show anything that could trigger this memory leak...
Comment 10 karaluh 2009-02-28 11:02:23 UTC
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.
Comment 11 Alexandre Lung 2009-04-15 14:11:17 UTC
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).
Comment 12 Aaron J. Seigo 2009-04-26 07:39:48 UTC
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)
Comment 13 Alexis MENARD 2009-04-26 08:00:17 UTC
wOOt. Pretty bad. I know the first thing i will do tomorrow :D.
Comment 14 Aaron J. Seigo 2009-04-26 08:12:08 UTC
hm.. i suppose i should mark this as upstream.
Comment 15 Alexis MENARD 2009-04-27 16:49:49 UTC
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.
Comment 16 Michael Seiwert 2009-05-05 17:44:47 UTC
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
Comment 17 Alexis MENARD 2009-05-05 19:02:29 UTC
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.
Comment 18 Aaron J. Seigo 2009-05-06 01:39:32 UTC
plasma as a whole or `plasmoidviewer digital-clock`?
Comment 19 Alexis MENARD 2009-05-06 09:52:48 UTC
Actually i didn't tried plasmoidviewer but i will do it. plasma-desktop was leaking.
Comment 20 Michael Seiwert 2009-05-06 10:34:49 UTC
@Alexis: 4.2 branch or 4.3 trunk ?
Comment 21 Alexis MENARD 2009-05-06 13:40:56 UTC
Trunk
Comment 22 Michael Seiwert 2009-05-07 07:02:41 UTC
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.
Comment 23 Aaron J. Seigo 2009-05-10 04:03:13 UTC
re-opening to track the next set of ensuing issues ...
Comment 24 Aaron J. Seigo 2009-05-10 04:03:37 UTC
*** Bug 183646 has been marked as a duplicate of this bug. ***
Comment 25 Aaron J. Seigo 2009-05-10 04:04:31 UTC
*** Bug 192190 has been marked as a duplicate of this bug. ***
Comment 26 Alexis MENARD 2009-05-22 09:57:01 UTC
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.
Comment 27 Michael Seiwert 2009-05-22 12:10:03 UTC
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!